Created attachment 214027 [details] [bhyve][PATCH] Append Keyboard Layout specified option for using VNC. When a guest OS is loaded using UEFI and connected with VNC, if the keyboard on the VNC client side is other than the US keyboard, some keys input may not be p erformed correctly. For example, if you press the '@' key on a Japanese keyboard, the number '2' will be entered on the guest OS. The cause is that the '@' key on the US keyboard is assigned to Shift + '2' keys. In addition, there is a problem that keys that do not exist on the US keyboard cannot be entered. (example, Zenkaku-Hankaku key in the Japanese Keyboard) In the current bhyve(13-Current & 12.1-RELEASE-p3), in the virtual PS2 keyboard driver, there is a conversion table that converts from the key entered from the VNC client side to the virtual keyboard ScanCode for the Guest OS. However, since this conversion table is set for US keyboards, the above problem will occur if the client side is not a US keyboard. Therefore, I created a patch that allows the conversion table to be set in the external configuration file for each keyboard layout, and that the configuration file (=keyboard layout) can be specified by the option '-k' of the bhyve command. The following shows how to apply the patch and how to use it. Please merge it into the source tree if possible. I'm new to creating a patch for the FreeBSD source tree, and I'm not sure if it's correct to submit to Bugzilla. If it's wrong to submit it to Bugzilla, it would be very helpful if you could tell me how to submit it. A. How to apply the patch ---------------------------------- 1. cd /usr/src/usr.sbin 2. patch -u < bhyve_kbdlayout_fbsd13c.patch 3. sh bhyve_kbdlayout.shar 4. cd /usr/src/usr.sbin/bhyve 5. make 6. make install * If you use the FreeBSD 12.1-RELEASE, please replace the "fbsd13c" of the above No.2 to the "fbsd121r". B. How to specified the keyboard layout -------------------- If you use the bhyve command directly, specify the '-k layout' option for the bhyve command. You can specify the "layout" in the file name stored in /usr/share/bhyve/kbdlayout dir. If no '-k' option is specified, the US keyboard (default) is assumed to be selected. Others, If you use the bhyve via the vm-bhyve package, specify the following lines for the Guest OS configure file. bhyve_options="-k layout" C. Request for Coooperation (The remaining tasks) ---------- Currently, the keyboard layout setting file can only be created for Japanese keyboards. (Because, I have only the Japanese Keyboard...) If you would like to adopt this patch, I would like to ask those who use keyboards of the corresponding languages to create keyboard layout setting files oth er than English and Japanese keyboards. See the 'default' file in the /usr/share/bhyve/kbdlayout dir. for how to create it.
It looks interesting, but can we use existing layout files: /usr/share/vt/keymaps or /usr/share/syscons/keymaps? See format description: man 5 kbdmap
Thank you for you interest in the patch. Unfortunately, I understand that the your suggestions are difficult for the following reasons. The virtual PS2 keyboard driver of the bhyve has a table for converting ASCII code for keys that can be expressed in ASCII characters and Xorg keysym code for keys that cannot be expressed in ASCII characters (example Enter or Escape key,etc) to ScanCode Set2 of the PS2 keyboard. This patch updates this conversion table based on the layout setting file. The /usr/share/vt/keymaps/* file contain the correspondence of ASCII characters or key names (key names is unique to vt/syscons, not Xorg keysym) corresponding to the scancode (for vt/syscons) converted from ScanCode Set2 of the PS2 keyboard device. In addition, I confirmed that the conversion algorithm from ScanCode Set2 of the PS2 keyboard to scancode (for vt/syscons) is implemented in /usr/src/sys/dev/atkbdc/atkbd.c, so I think that it is not impossible to use the /usr/share/vt/keymaps/* file as the basis for the keys that can be represented by ASCII characters. (Since it has not been examined in detail, I don't understand whether ScanCode Set2 of the PS2 keyboard can actually be converted from scancode (for vt/syscons) to the reverse.) On the other hand, a key that cannot be represented by ASCII characters cannot be supported because the value of Xorg keysym value doesn't exist in /usr/share/vt/keymaps/* file. (For reference, the value of Xorg keysym value is in the /usr/local/include/X11/keysymdef.h) Therefore, even if the key layout conversion information that can be expressed in ASCII characters is acquired from /usr/share/vt/keymaps/* file, the key that cannot be expressed in ASCII characters cannot be acquired from /usr/share/vt/keymaps/* file, and thus I think that a layout configuration file for each language is required. If you have a good idea to use /usr/share/vt/keymaps/* file, please let me know. (I also don't want to have a layout configuration file for bhyve apart from /usr/share/vt/keymaps/* file. But I did this because I couldn't think of any other simple way...) - Koine Yuusuke (koinec)
Another way to solve this is to implement the "QEMU Extended Key Event Message" in the server (https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#qemu-extended-key-event-message) This allows scancodes to be sent end-end so avoids information loss and locale mis-translation when converting VNC keycodes to PS2 scancodes. The downside is that client support is patchy :( It's in recent versions of TigerVNC and originated fron NoVMC, but isn't in VNCViewer, tightVNC or UltraVNC :( However, it avoids the problem of having to create per-language maps.
There's at least a workaround to make non-english keyboards work: In the bhyve client configure the keyboard to your locale, e.g. de, jp, ... On the host running the VNC client change your keyboard setting to "us" e.g. "setxkbmap us". Then connect using TigerVNC or probably other clients. Inside the VNC client all keys e.g. German umlauts should work normally.
Created attachment 214725 [details] [bhyve][PATCH] Append Keyboard Layout specified option for using VNC. Thank you for the various ideas! As a result of thinking, I think that the method that has the keyboard-layout setting file is better. However, I tried to automatically generate the keyboard-layout setting file for each language from the file existing /usr/share/vt/kbdmap for vt, so update the generated keyboard-layout patch files for each language. Now that I can enter the following keys on the keyboards of all languages supported by vt, what about? A. How to apply the patch ---------------------------------- 1. cd /usr/src/usr.sbin 2. patch -u < bhyve_kbdlayout_fbsd13c.patch 3. sh bhyve_kbdlayout.shar (*Updated the bhyve_kbdlayou.shar file in this time.) 4. cd /usr/src/usr.sbin/bhyve 5. make 6. make install * If you use the FreeBSD 12.1-RELEASE, please replace the "fbsd13c" of the above No.2 to the "fbsd121r". B. Supoorting Keyboard map --------------------------------- You can use the following keyboard language layout. (Indicates the string that can be specified in the bhyve -k option.) am / be / be_acc / bg_bds / bg_phonetic / br / br_noacc / by ca / ca-fr / centraleuropean / centraleuropean_qwerty ch / ch_acc / ch-fr / ch-fr_acc / ch_macbook_acc / colemak_acc cz / de / de_acc / de_noacc / dk / dk_acc / dk_macbook ee / es / es_acc / es_dvorak / fi fr / fr_acc / fr_dvorak / fr_dvorak_acc / fr_macbook gr / gr_101_acc / gr_elot_acc / hr / hu_101 / hu_102 il / is / is_acc / it / kz_io / kz_kst / lt latinamerican / latinamerican_acc / nl / no / no_dvorak / nordic_asus-eee pl / pl_dvorak / pt / pt_acc / ru / ru_shift / ru_win / se / si / sk tr / tr_f / ua / ua_shift_alt / uk / uk_capsctrl / uk_dvorak / uk_macbook us / us_acc / us_ctrl / us_emacs / us_macbook / us_unix us_dvorak / us_dvorakl / us_dvorakp / us_dvorakr / us_dvorakx jp / jp_capsctrl C. Supporting Key with the above Keyboard-Layout file. ---- Alphabetical Key ( [a-zA-Z] ) Numeric Key ( [0-9] ) Sign mark Key ( !"#$%&'()+-*/=^~\|@`[]{};:,.<>?_ ) Enter / Escape / Tab / Shift(L/R) / Ctrl.(L/R) / Alt(L/R) / Home / End / Ins. / BackSpace / Delete Up Arrow / Down Arrow / Left Arrow / Right Arrow / PgUp / PgDown F1-12 / WinKey(L/R) * jp / jp_capsctl supports Japanese keyboard specific keys. D. Thoghts on the ideas you taught ------------------------ 1. The workaround by executing "setxkbmap us" on the VNC client side. This method allows the guest OS to enter the correct key input, but there is a problem that the key cannot be input correctly on the client side(HyberVisor) terminal. Therefore, it is not possible to use the FreeBSD terminal on which bhyve runs and the guest OS as the same time. I knew it was also introduced as a workaround on other sites, but I patched this thread because of the above issue. 2. The use of QEMU Extended Key Event Message I understand that this method is a drastic measure to avoid using the keyboard-layout files, and I would like to make the patch with it if possible ... However, in the current VNC clients that exist the FreeBSD ports, tigerVNC doesn't support this message because it is an old version, and it seems that tightVNC & ssvnc doesn't support this message in the first place. If the VNC clients that exist the FreeBSd ports supprots this message, I would like to try to support this message, but I can not support it because there is no VNCclient currently. And as far as I can see the bhyve source tree, I think the difficulty level of the modification is high. 3. This proposal When we aim to make it easy to use any language using the current VNCclient on FreeBSD ports, I think that it is unavoidable to use the keyboard-layout setting file. However, it is difficult to create the keyboard-layout files for each launguage from the beginning, so the minimum keys such as alphabets, numbers, and symbols were automatically generated. I would like to ask if this method is acceptable, test the generating keyboard-layout setting file for each language, and add a unique key definition for each language.
TigerVNC in ports is v1.10.1, which is the latest official release. The Qemu key event code has been in there for a couple of years now. I'll have a look at how much work it is to support that extension, but I grant that a) it isn't supported by other VNC clients, and b) the performance of TigerVNC is worse than TightVNC. So, the keymap change is still likely worthwhile. I'll take a closer look at your patch.
Created attachment 215004 [details] [bhyve][PATCH] Support QEMU Extended Key Event Message and Append keyboard layout specified option. Thank you for telling me and I'm sorry for my lack of research. With you help, I found that the TigerVNC supports QEMU Extended Key Event Message, so I immediately tried to create a patch. As a result, when using TigerVNC, it is possible to support keys unique of each language without depending the keyboard layout setting file or specifying bhyve -k option. However, I would like to preserve the keyboard layout configuration file and the bhyve -k option feature to allow use by VNC clients that don't support QEMU Extended Key Event Messages (such as tightVNC). By the last time, the keyboard layout setting file should have been able to input alphabets, numbers, symbols, and a part of functional key(e.g. Enter/Space) in every languages keyboard, so I think that support has advanced considerably, but what about? A. How to apply the NEW patch -------------------------------------------- Same as last time. (See above) B. Usage ----------------------------------------------------------------- * VNC clients with supported the QEMU Extended Key Event Mesage (TigerVNC) Just use it as before. The keyboard layout of each language is automatically supported. Even if the -k option is specified, it will be ignored. * VNC clients WITHOUT supported the message (tightVNC, ssvnc, etc) You need to specify the keyboard layout name by the -k option. The method of specify the -k option is same as last time. If not specified, the US keyboard layout is assumed to have been specified. I apologize for fixing the path many times, but I appreciate your cooperation.
Thanks - great work :) I'll split this out into 2 parts. The first will be support for the qemu extended key event message, since this requires no documentation, and can provide a solution today for those willing to use TigerVNC (and it will also provide some impetus to fix the perf issues with TigerVNC). I'll put up a review for this shortly. The second will be adding support for the translation-table file.
Created attachment 215195 [details] [PATCH] supporting QEMU Extended Keyboard Event Message Thank you for everything. The patch has been divided into two parts, so please use it if you like. The first patch is "bhyve_qemu_ext_key_event_msg.tgz" for supporting QEMU Extended Keyboard Event Message. It can be applied by executing the following command on /usr/src/usr.sbin patch -u < bhyve_qemu_ext_key_event_msg_fbsd13c.patch * If you use the FreeBSD 12.1-RELEASE, please replace the "fbsd13c" of the above to the "fbsd121r".
Created attachment 215196 [details] [PATCH] Append bhyve -k option for specified keyboard layout with layout setting files every languages. Then, the second patch is "bhyve_kbdlayout_option.tgz" for supporting bhyve -k option that specify the keyboard layout name. This patch can be applied be executing the following command. cd /usr/src/usr.sbin patch -u < bhyve_kbdlayout_option_fbsd13c.patch sh bhyve_kbdlayout_layoutfile.shar cd /usr/src/share patch -u < bhyve_kbdlayout_vmrunsh_fbsd13c.patch In addition, the second patch has the following changes from the previous patch. * The first patch (for supporting QEMU Extended Keyboard Event Message) must be applied before applying this patch. * Fix an issue where the latest bhyve source tree (only FreeBSD 13.0-current) could not be patched correctly. (SORRY!) * Modified so that -k option can be specified from /usr/share/examples/bhyve/vmrun.sh. (However, vmrun.sh is only modified.) If there is something, please point out.
(In reply to Koine Yuusuke from comment #9) Thanks for the patch. I'd already broken out that section from your previous one so the review might look slightly different. One issue I had with the qemu ext keyevent is that TigerVNC generates scanset 1 codes (with freebsd/macos/windows clients), whereas the atkbd emulation is expecting scanset 2 codes in the FIFO. There's a simple 1:1 translation between scanset 1 and 2, so I'll add a table for that conversion.
(In reply to Peter Grehan from comment #11) Thank you for responding. I think it is unnecessary to add a translation table from scanset2 to scanset 1. In the patch suggested this time, the translation process from scanset 2 to scanset 1 is bypassed in the atkbd emulation only when the QEMU Extended Key Event Message is received. (Therefore, an argument that specifies whether scanset conversion is performed is added to the fifo_get() function and fifo_put() function arguments.) There are two reasons for doing this. 1) It is written that a simple 1:1 translation is possible from scanset2 to scanset 1, but I understand the following exceptions. Scanset 2 Scanset 1 ----------------------------- 0x02/0x83 -> 0x41 0x7f/0x84 -> 0x54 There is no problem when tranlating from scanset 2 to scanset 1 as int the atkbd emulation, but when performing reverse tranlation, it is the recognition that 0x41/0x54 of scanset 1 cannot determine which value of scanset 2 is set. (However, as far as I know, this is only the F7 key(0x83->0x41), so it may not be a problem ...) 2) In bhyve's code, translating from scanset 1 to scanset 2 in ps2kbd.c, and then translating from scanset 2 to scanset 1 in atkbd.c again immediately, it is considered redundant even if the effect on performance is slight I will. In the future, if we decide to make the atkbd emulation(atkbdc.c) and PS2 virtual keyboard driver(ps2kbd.c) completely independent, I'm aware that there is a problem because the method suggested this time will not be able to make them independent. However, in the current implementation, the function of the PS2 virtual keyboard driver is directly called from the atkbd emulation, so I couldn't understand the future course. If necessary, I can stop the bypass process and add the translation process from scanset 1 to scanset 2. I apologize for the inconvenience, but please would like to know the correspondence policy.
I'm not concerned at the double translation. scanset 1 is only used for BIOS/DOS applications so performance not an issue there. For the 2 cases you mentioned where there is an ambiguous translation from 1 to 2, I think it's fine to use the 83/84 scanset 2 values - I wasn't able to find any references to the 02/7f so assuming they are rare, and in addition, the translation is not generic for XT keyboards, but is only for VNC clients which are much more recent.
Created attachment 215545 [details] [PATCH] supporting QEMU Extended Keyboard Event Message Thank you for letting me know the implement policy. You may have corrected it, but I also tried recreating the patch for my study. I would appreciate it if you could use it. It's my first time proposing a patch to FreeBSD Base System, so I don't understand what to do in the future. If there is something, please point out.
Created attachment 215546 [details] [PATCH] Append bhyve -k option for specified keyboard layout with layout setting files every languages. The patch of the layout specification option by the setting file was also fixed. Please consider adopting this patch as well.
(In reply to Koine Yuusuke from comment #14) Thanks for the update ! I'll incorporate that and test it out.
Hi, I'm currently testing the patches with FreeBSD 12.2 STABLE. Using both patches: cd /usr/src patch < bhyve_qemu_ext_key_event_msg_fbsd121r.patch patch < bhyve_kbdlayout_option_fbsd121r.patch sh bhyve_kbdlayout_layoutfile.shar ls -l bhyve/*.rej -rw-r--r-- 1 root wheel 199 4 Nov. 16:15 bhyve/bhyve.8.rej -rw-r--r-- 1 root wheel 273 4 Nov. 16:15 bhyve/bhyverun.c.rej -rw-r--r-- 1 root wheel 1167 3 Nov. 21:52 bhyve/ps2kbd.c.rej If only using bhyve_qemu_ext_key_event_msg_fbsd121r.patch: This seems to work as I can switch to a german layout (Windows10 VM) and use umlauts. If only using bhyve_kbdlayout_option_fbsd121r.patch: The patch doesn't apply cleanly: -rw-r--r-- 1 root wheel 199 4 Nov. 16:35 bhyve/bhyve.8.rej -rw-r--r-- 1 root wheel 273 4 Nov. 16:35 bhyve/bhyverun.c.rej make install doesn't call kbdlayout/Makefile BTW. If applying bhyverun.c.rej by hand I can start bhyve with 'bhyve_options="-k de"' but doesn't seem to work like the first patch. (I can select the german keyboard in Windows but no umlauts are printed) So it seems that for me only bhyve_qemu_ext_key_event_msg_fbsd121r.patch is working as expected. Thanks for your work in this area BTW!
Just for sharing, I'm using also the bhyve_qemu_ext_key_event_msg_fbsd121r.patch from the first time I found it on the ML on my FreeBSD 12.1 box (which is now running FreeBSD 12.2). It finally allows me to use correctly my Italian keyboard layout on my VMs. I have it also on my T495 running 13-current. It would be very nice to include it in the official repo.
There is some activity on VNC (and TigerVNC client perf) in PR 250795 so I think the qemu ext kbd change could drop in when that is done.
I did try out this patch with freebsd 13, and it does work as advertised (I tried with fi keymap & TigerVNC 1.11.0). I found no issues. I applied the patch on top of the patch from PR 250795.
Thank you everyone for reporting. When I tried it on FreeBSD 12.2-RELEASE, it was as follows. - bhyve_qemu_ext_key_event_msg_fbsd121r.patch: OK - bhyve_kbdlayout_option_fbsd121r.patch: NG (.rej occurs in bhyverun.c & bhyve.8 (man)) (I have just applied the patch and have not tested it yet.) In Comment 17, I received a report that FreeBSD 12.2 Stable will generate ps2kbd.c.rej, but when was the updated source? (Is it a newer source than 12.2-RELEASE?) The cause of the problem that the .rej file is generated by bhyve_kbdlayout_option_fbsd121r.patch in 12.2-RELEASE is known, so I would like to post a correction patch at a later date.
Created attachment 221184 [details] [PATCH] Append bhyve -k option for specified keyboard layout with layout setting files every languages. A happy new year! I have created a patch for FreeBSD 12.2-RELEASE. I also checked the operation on FreeBSD 13.0-current(20201224) and updated the patch. I will upload the latest patch, so please give it a try.
Created attachment 221185 [details] [PATCH] supporting QEMU Extended Keyboard Event Message In addtion, I fixed an issue where qemu-extended-key-event patch could not be applied correctly on FreeBSD 13.0-current(20201224) and 12.2-RELEASE. Pleases try this patch as well.
Hi, do you have by chance updated patches for stable/12 and main? For me bhyve_kbdlayout_option_fbsd122r.patch doesn't seem to work as intended. Running a Windows 10 VM with '-k de' and setting the Windows KBD-Lang to 'deu' seems to work for the intended Layout for Keys like '\|-_' but I don't get Umlauts or €... Also the bhyve_qemu_ext_key_event_msg patch doesn't apply cleanly on top of the hyve_kbdlayout_option patch: Patching file bhyve/ps2kbd.c using Plan A... Hunk #1 succeeded at 185 (offset 7 lines). Hunk #2 failed at 339. Hunk #3 succeeded at 382 (offset 7 lines). Hunk #4 succeeded at 393 (offset 7 lines). 1 out of 4 hunks failed--saving rejects to bhyve/ps2kbd.c.rej
(In reply to Michael Reifenberger from comment #24) Thank you for reporting the results. > Hi,do you have by chance updated patches for stable/12 and main? > > For me bhyve_kbdlayout_option_fbsd122r.patch doesn't seem to work as intended. > > Running a Windows 10 VM with '-k de' and setting the Windows KBD-Lang to 'deu' > seems to work for the intended Layout for Keys like '\|-_' but I don't get > Umlauts or ???... Currently, bhyve_kbdlayout_option_fbsd***.patch doesn't support language-specific keys other than alphabets, numbers, ASCII code symbols(e.g. !/#/$/etc), and control keys (Enter, Escape, Space, etc.) that are also found on US keyboards. Because I only have a Japanese keyboard, I don't know what keys are on keyboards in other languages, how to type them, and what keycodes are output as a result. For this reason, you should not be able to enter umlauts, etc. If possible, I would be grateful if you could add the settings specific to the German keyboard to the "/usr/share/bhyve/kbdlayout/de" file. This file has the following syntax. ---- '<ascii char>', hex (1byte); comment hex (1or2byte), hex (1byte); comment ---- The first data is the state of the console that does not start Xorg, and if the character is displayed by pressing the key, enter the character separated by quotes. If the control key does not display characters, enter the value of keysym displayed when the corresponding key is entered with the xev command in hexadecimal. However, since umlauts are one letter in German, not control keys, I'm sorry I don't know if they can be represented by Xorg's keysym. For the second data, enter the scancode (type2) value of the keyboard of each language corresponding to that key. The value of scancode differs depending on the keyboard of each language, so please check it with google etc. Then write a semicolon to mark the end of the line. The line after the semicolon is considered a comment. I'm sorry I think it's difficult, but if you understand it, please set it. > Also the bhyve_qemu_ext_key_event_msg patch doesn't apply cleanly on top of the > hyve_kbdlayout_option patch: > > Patching file bhyve/ps2kbd.c using Plan A... > Hunk #1 succeeded at 185 (offset 7 lines). > Hunk #2 failed at 339. > Hunk #3 succeeded at 382 (offset 7 lines). > Hunk #4 succeeded at 393 (offset 7 lines). > 1 out of 4 hunks failed--saving rejects to bhyve/ps2kbd.c.rej bhyve_kbdlayout_option_fbsd***.patch does not assume apply prior to bhyve_qemu_ext_key_event_msg_fbsd***.patch. For this reason, I'm sorry, but I would like you to apply bhyve_qemu_ext_key_event_msg_fbsd***.patch first and then bhyve_kbdlayout_option_fbsd***.patch to the original bhyve source code. Finally, I launched the git site for this patch, and in addition to the patch, I also released a tool to generate a layout file from a kbd file for FreeBSD's vt, so please refer to it. https://osdn.net/users/koinec/pf/bhyve_keyboard_layout_patch/wiki/FrontPage Best regards.
Hi, yes. After applying bhyve_qemu_ext_key_event_msg_fbsd***.patch first and then bhyve_kbdlayout_option_fbsd***.patch to the original bhyve source code it applies mostly clean and works as intended. In Windows even Umlauts show up. Thanks for your work! Now lets try to get it committed.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=b563ff5d4f812df198ade6991834782a5d35af08 commit b563ff5d4f812df198ade6991834782a5d35af08 Author: Michael Reifenberger <mr@FreeBSD.org> AuthorDate: 2021-04-21 10:38:26 +0000 Commit: Michael Reifenberger <mr@FreeBSD.org> CommitDate: 2021-04-21 10:40:44 +0000 Append Keyboard Layout specified option for using VNC. Part one: supporting QEMU Extended Keyboard Event Message PR: 246121 Submitted by: koinec@yahoo.co.jp Differential Revision: https://reviews.freebsd.org/D29430 usr.sbin/bhyve/console.c | 4 +-- usr.sbin/bhyve/console.h | 4 +-- usr.sbin/bhyve/ps2kbd.c | 54 ++++++++++++++++++++++++++---------- usr.sbin/bhyve/rfb.c | 72 +++++++++++++++++++++++++++++++++++++++++++++++- 4 files changed, 115 insertions(+), 19 deletions(-)
Hello. I have the same problem explained here and I tried to apply the patch as follows : but Im not sure if it worked / how much it worked...what do u think ? I've got the patch file here : https://osdn.net/users/koinec/pf/bhyve_keyboard_layout_patch/scm/blobs/b0817c73acee1ed5a2b3621590fa6fc1cca89425/kbdlayout_option/bhyve_kbdlayout_fbsd13c.patch root@marietto:/usr/src/usr.sbin # patch -u < bhyve_kbdlayout_fbsd13c.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -upN bhyve_orig/Makefile bhyve/Makefile |--- bhyve_orig/Makefile 2020-04-23 09:06:39.000000000 +0900 |+++ bhyve/Makefile 2020-05-02 13:09:01.382770000 +0900 -------------------------- Patching file Makefile using Plan A... Hunk #1 failed at 99. 1 out of 1 hunks failed--saving rejects to Makefile.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -upN bhyve_orig/bhyve.8 bhyve/bhyve.8 |--- bhyve_orig/bhyve.8 2020-04-23 09:06:39.000000000 +0900 |+++ bhyve/bhyve.8 2020-05-02 13:11:28.198679000 +0900 -------------------------- Patching file bhyve/bhyve.8 using Plan A... Hunk #1 failed at 47. Hunk #2 succeeded at 150 (offset -12 lines). 1 out of 2 hunks failed--saving rejects to bhyve/bhyve.8.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -upN bhyve_orig/bhyverun.c bhyve/bhyverun.c |--- bhyve_orig/bhyverun.c 2020-04-23 09:06:39.000000000 +0900 |+++ bhyve/bhyverun.c 2020-05-02 13:09:01.437624000 +0900 -------------------------- Patching file bhyve/bhyverun.c using Plan A... Hunk #1 succeeded at 188 (offset 20 lines). Hunk #2 failed at 239. Hunk #3 succeeded at 230 with fuzz 1 (offset 1 line). Hunk #4 failed at 1024. Hunk #5 succeeded at 1146 (offset 85 lines). 2 out of 5 hunks failed--saving rejects to bhyve/bhyverun.c.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -upN bhyve_orig/bhyverun.h bhyve/bhyverun.h |--- bhyve_orig/bhyverun.h 2020-04-23 09:06:39.000000000 +0900 |+++ bhyve/bhyverun.h 2020-05-02 13:09:01.444814000 +0900 -------------------------- Patching file bhyve/bhyverun.h using Plan A... Hunk #1 failed at 39. 1 out of 1 hunks failed--saving rejects to bhyve/bhyverun.h.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Common subdirectories: bhyve_orig/kbdlayout and bhyve/kbdlayout |diff -upN bhyve_orig/ps2kbd.c bhyve/ps2kbd.c |--- bhyve_orig/ps2kbd.c 2020-04-23 09:06:39.000000000 +0900 |+++ bhyve/ps2kbd.c 2020-05-02 13:09:01.462761000 +0900 -------------------------- Patching file bhyve/ps2kbd.c using Plan A... Hunk #1 failed at 31. Hunk #2 succeeded at 67 (offset 3 lines). Hunk #3 succeeded at 97 (offset 3 lines). Hunk #4 succeeded at 169 (offset 3 lines). Hunk #5 succeeded at 327 (offset 3 lines). Hunk #6 succeeded at 377 (offset 3 lines). 1 out of 6 hunks failed--saving rejects to bhyve/ps2kbd.c.rej done
root@marietto:/usr/src/usr.sbin # sh bhyve_kbdlayout.shar sh: cannot open bhyve_kbdlayout.shar: No such file or directory root@marietto:/usr/src/usr.sbin # cd /usr/src/usr.sbin/bhyve root@marietto:/usr/src/usr.sbin/bhyve # make [Creating objdir /usr/obj/usr/src/amd64.amd64/usr.sbin/bhyve...] echo bhyve.full: /usr/lib/libc.a /usr/lib/libvmmapi.a /usr/lib/libmd.a /usr/lib/libpthread.a /usr/lib/libz.a /usr/lib/libutil.a /usr/lib/libsbuf.a /usr/lib/libcam.a /usr/lib/lib9p.a /usr/lib/libnetgraph.a /usr/lib/libcrypto.a >> .depend ...... cc -O2 -pipe -fno-common -I/usr/src/usr.sbin/bhyve/../../contrib/lib9p -I/usr/src/sys -DINET -DINET6 -DNETGRAPH -I/usr/src/sys/dev/e1000 -I/usr/src/sys/dev/mii -I/usr/src/sys/dev/usb/controller -g -MD -MF.depend.ps2kbd.o -MTps2kbd.o -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/usr.sbin/bhyve/ps2kbd.c -o ps2kbd.o /usr/src/usr.sbin/bhyve/ps2kbd.c:407:14: error: variable has incomplete type 'struct stat' struct stat sb; ^ /usr/src/usr.sbin/bhyve/ps2kbd.c:407:9: note: forward declaration of 'struct stat' struct stat sb; ^ /usr/src/usr.sbin/bhyve/ps2kbd.c:413:16: error: use of undeclared identifier 'kbdlayout_name' strncat(path, kbdlayout_name, (sizeof(path) - strlen(PS2KBD_LAYOUT_BASEDIR) - 1)); ^ /usr/src/usr.sbin/bhyve/ps2kbd.c:415:8: error: implicit declaration of function 'stat' is invalid in C99 [-Werror,-Wimplicit-function-declaration] err = stat(path, &sb); ^ /usr/src/usr.sbin/bhyve/ps2kbd.c:423:7: error: implicit declaration of function 'open' is invalid in C99 [-Werror,-Wimplicit-function-declaration] fd = open(path, O_RDONLY); ^ /usr/src/usr.sbin/bhyve/ps2kbd.c:423:18: error: use of undeclared identifier 'O_RDONLY' fd = open(path, O_RDONLY); ^ /usr/src/usr.sbin/bhyve/ps2kbd.c:427:7: error: implicit declaration of function 'read' is invalid in C99 [-Werror,-Wimplicit-function-declaration] sz = read(fd, buf, sb.st_size ); ^ /usr/src/usr.sbin/bhyve/ps2kbd.c:427:7: note: did you mean 'fread'? /usr/include/stdio.h:263:9: note: 'fread' declared here size_t fread(void * __restrict, size_t, size_t, FILE * __restrict); ^ /usr/src/usr.sbin/bhyve/ps2kbd.c:429:2: error: implicit declaration of function 'close' is invalid in C99 [-Werror,-Wimplicit-function-declaration] close(fd); ^ /usr/src/usr.sbin/bhyve/ps2kbd.c:458:6: error: use of undeclared identifier 'kbdlayout_name' if (kbdlayout_name != NULL) ^ 8 errors generated. *** Error code 1 Stop. make: stopped in /usr/src/usr.sbin/bhyve
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=19eaa01beaba68ed4c70c44127955f5c9b331cb9 commit 19eaa01beaba68ed4c70c44127955f5c9b331cb9 Author: Michael Reifenberger <mr@FreeBSD.org> AuthorDate: 2022-01-20 22:44:04 +0000 Commit: Michael Reifenberger <mr@FreeBSD.org> CommitDate: 2022-01-20 22:49:27 +0000 Append Keyboard Layout specified option for using VNC. Part two: Append bhyve -K option for specified keyboard layout with layout setting files every languages. Since the cmd option '-k' was used in the meantime it was changed to '-K' PR: 246121 Submitted by: koinec@yahoo.co.jp Reviewed by: grehan@ Differential Revision: https://reviews.freebsd.org/D29473 MFC after: 4 weeks etc/mtree/BSD.usr.dist | 4 + usr.sbin/bhyve/Makefile | 1 + usr.sbin/bhyve/bhyve.8 | 8 + usr.sbin/bhyve/bhyve_config.5 | 6 + usr.sbin/bhyve/bhyverun.c | 8 +- usr.sbin/bhyve/kbdlayout/Makefile (new) | 40 ++++ usr.sbin/bhyve/kbdlayout/Makefile.depend (new) | 11 + usr.sbin/bhyve/kbdlayout/am (new) | 10 + usr.sbin/bhyve/kbdlayout/be (new) | 45 ++++ usr.sbin/bhyve/kbdlayout/be_acc (new) | 42 ++++ usr.sbin/bhyve/kbdlayout/bg_bds (new) | 10 + usr.sbin/bhyve/kbdlayout/bg_phonetic (new) | 9 + usr.sbin/bhyve/kbdlayout/br (new) | 19 ++ usr.sbin/bhyve/kbdlayout/br_noacc (new) | 22 ++ usr.sbin/bhyve/kbdlayout/centraleuropean (new) | 12 ++ usr.sbin/bhyve/kbdlayout/ch (new) | 36 ++++ usr.sbin/bhyve/kbdlayout/ch-fr (new) | 36 ++++ usr.sbin/bhyve/kbdlayout/ch-fr_acc (new) | 33 +++ usr.sbin/bhyve/kbdlayout/ch_acc (new) | 33 +++ usr.sbin/bhyve/kbdlayout/ch_macbook_acc (new) | 37 ++++ usr.sbin/bhyve/kbdlayout/cz (new) | 11 + usr.sbin/bhyve/kbdlayout/de (new) | 37 ++++ usr.sbin/bhyve/kbdlayout/de_acc (new) | 36 ++++ usr.sbin/bhyve/kbdlayout/de_noacc (new) | 38 ++++ usr.sbin/bhyve/kbdlayout/default (new) | 248 +++++++++++++++++++++++ usr.sbin/bhyve/kbdlayout/dk (new) | 32 +++ usr.sbin/bhyve/kbdlayout/dk_macbook (new) | 35 ++++ usr.sbin/bhyve/kbdlayout/ee (new) | 31 +++ usr.sbin/bhyve/kbdlayout/es (new) | 28 +++ usr.sbin/bhyve/kbdlayout/es_acc (new) | 28 +++ usr.sbin/bhyve/kbdlayout/es_dvorak (new) | 78 +++++++ usr.sbin/bhyve/kbdlayout/fi (new) | 32 +++ usr.sbin/bhyve/kbdlayout/fr (new) | 46 +++++ usr.sbin/bhyve/kbdlayout/fr_acc (new) | 46 +++++ usr.sbin/bhyve/kbdlayout/fr_dvorak (new) | 87 ++++++++ usr.sbin/bhyve/kbdlayout/fr_dvorak_acc (new) | 86 ++++++++ usr.sbin/bhyve/kbdlayout/fr_macbook (new) | 49 +++++ usr.sbin/bhyve/kbdlayout/gr (new) | 9 + usr.sbin/bhyve/kbdlayout/gr_101_acc (new) | 9 + usr.sbin/bhyve/kbdlayout/gr_elot_acc (new) | 17 ++ usr.sbin/bhyve/kbdlayout/hr (new) | 36 ++++ usr.sbin/bhyve/kbdlayout/hu_101 (new) | 9 + usr.sbin/bhyve/kbdlayout/hu_102 (new) | 41 ++++ usr.sbin/bhyve/kbdlayout/is (new) | 33 +++ usr.sbin/bhyve/kbdlayout/is_acc (new) | 32 +++ usr.sbin/bhyve/kbdlayout/it (new) | 34 ++++ usr.sbin/bhyve/kbdlayout/jp (new) | 36 ++++ usr.sbin/bhyve/kbdlayout/jp_capsctrl (new) | 37 ++++ usr.sbin/bhyve/kbdlayout/kz_io (new) | 11 + usr.sbin/bhyve/kbdlayout/kz_kst (new) | 11 + usr.sbin/bhyve/kbdlayout/latinamerican (new) | 33 +++ usr.sbin/bhyve/kbdlayout/latinamerican_acc (new) | 31 +++ usr.sbin/bhyve/kbdlayout/lt (new) | 10 + usr.sbin/bhyve/kbdlayout/nl (new) | 31 +++ usr.sbin/bhyve/kbdlayout/no (new) | 32 +++ usr.sbin/bhyve/kbdlayout/no_dvorak (new) | 81 ++++++++ usr.sbin/bhyve/kbdlayout/nordic_asus-eee (new) | 32 +++ usr.sbin/bhyve/kbdlayout/pl_dvorak (new) | 74 +++++++ usr.sbin/bhyve/kbdlayout/pt (new) | 31 +++ usr.sbin/bhyve/kbdlayout/pt_acc (new) | 28 +++ usr.sbin/bhyve/kbdlayout/ru (new) | 14 ++ usr.sbin/bhyve/kbdlayout/ru_shift (new) | 9 + usr.sbin/bhyve/kbdlayout/ru_win (new) | 9 + usr.sbin/bhyve/kbdlayout/se (new) | 32 +++ usr.sbin/bhyve/kbdlayout/si (new) | 36 ++++ usr.sbin/bhyve/kbdlayout/tr (new) | 36 ++++ usr.sbin/bhyve/kbdlayout/tr_f (new) | 81 ++++++++ usr.sbin/bhyve/kbdlayout/ua (new) | 9 + usr.sbin/bhyve/kbdlayout/ua_shift_alt (new) | 10 + usr.sbin/bhyve/kbdlayout/uk (new) | 14 ++ usr.sbin/bhyve/kbdlayout/uk_capsctrl (new) | 14 ++ usr.sbin/bhyve/kbdlayout/uk_dvorak (new) | 78 +++++++ usr.sbin/bhyve/kbdlayout/uk_macbook (new) | 10 + usr.sbin/bhyve/kbdlayout/us_dvorak (new) | 74 +++++++ usr.sbin/bhyve/kbdlayout/us_dvorakl (new) | 88 ++++++++ usr.sbin/bhyve/kbdlayout/us_dvorakp (new) | 95 +++++++++ usr.sbin/bhyve/kbdlayout/us_dvorakr (new) | 86 ++++++++ usr.sbin/bhyve/kbdlayout/us_dvorakx (new) | 80 ++++++++ usr.sbin/bhyve/kbdlayout/us_emacs (new) | 9 + usr.sbin/bhyve/kbdlayout/us_unix (new) | 14 ++ usr.sbin/bhyve/ps2kbd.c | 95 ++++++++- 81 files changed, 2956 insertions(+), 5 deletions(-)
Is it possible to get this merged for the upcoming 13.1 release?
(In reply to Ali Abdallah from comment #31) The two patches b563ff5d4f81 and 19eaa01beaba apply correctly to releng/13.1 branch, it would be nice to cherry-pick them for the upcoming 13.1 RELEASE
I'll try. I dont know it it still can be merged to 13.1 in time. Otherwise for 13.2 then.
I've tried to patch again bhyve using the "bhyve_keyboard_layout_patch" that I've found here : https://osdn.net/downloads/users/37/37604/bhyve_keyboard_layout_patch_20220121.tgz/ All the files seem to be patched correctly,but I got an error when I gave a "make". The error is the one below : cd: /usr/src/usr.sbin/bhyve/kbdlayout: No such file or directory I've saved the full log to show you what I did and what happened : https://pastebin.ubuntu.com/p/dmDs2jFTjw/ I'm running this version of FreeBSD : mario@marietto:/usr/src/usr.sbin/bhyve # uname -a FreeBSD marietto 13.0-RELEASE-p8 FreeBSD 13.0-RELEASE-p8 #7 n244863-45b90a014c11-dirty: Wed Mar 23 16:33:10 CET 2022 marietto@marie tto:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
Can this go into 12-STABLE as well?
Hello. actually I'm running FreeBSD 13.1-RELEASE. I've tried to apply this patch using two approach : 1) I've applied the patches to the 13.1-RELEASE files 2) I've copied the files already patched that Ive used on the 13.0-RELEASE on the /usr/src/usr.sbin folder of the 13.1-RELEASE and then I gave a "make" In both cases I've got the same error. case 1) # patch -u < /home/marietto/Desktop/Files/Scripts/FreeBSD/bhyve-corvin/bhyve_keyboard_layout_patch/qemu_ext_keyevent_msg/bhyve_qemu_ext_key_event_msg_fbsd130r.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -uprN bhyve_orig/console.c bhyve/console.c |--- bhyve_orig/console.c 2021-04-09 09:24:13.000000000 +0900 |+++ bhyve/console.c 2021-05-03 13:11:57.869902000 +0900 -------------------------- Patching file bhyve/console.c using Plan A... Hunk #1 succeeded at 106. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -uprN bhyve_orig/console.h bhyve/console.h |--- bhyve_orig/console.h 2021-04-09 09:24:13.000000000 +0900 |+++ bhyve/console.h 2021-05-03 13:11:57.870288000 +0900 -------------------------- Patching file bhyve/console.h using Plan A... Hunk #1 succeeded at 34. Hunk #2 succeeded at 47. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -uprN bhyve_orig/ps2kbd.c bhyve/ps2kbd.c |--- bhyve_orig/ps2kbd.c 2021-04-09 09:24:13.000000000 +0900 |+++ bhyve/ps2kbd.c 2021-05-03 13:11:57.870908000 +0900 -------------------------- Patching file bhyve/ps2kbd.c using Plan A... Hunk #1 succeeded at 181. Hunk #2 succeeded at 335. Hunk #3 succeeded at 378. Hunk #4 succeeded at 389. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -uprN bhyve_orig/rfb.c bhyve/rfb.c |--- bhyve_orig/rfb.c 2021-04-09 09:24:13.000000000 +0900 |+++ bhyve/rfb.c 2021-05-03 13:13:08.713857000 +0900 -------------------------- Patching file bhyve/rfb.c using Plan A... Hunk #1 succeeded at 98. Hunk #2 succeeded at 119. Hunk #3 succeeded at 174. Hunk #4 succeeded at 204. Hunk #5 succeeded at 297. Hunk #6 succeeded at 350. Hunk #7 succeeded at 730. Hunk #8 succeeded at 747. Hunk #9 succeeded at 1061. Hunk #10 succeeded at 1098. done ..... make[1]: /usr/obj/usr/src/amd64.amd64/usr.sbin/makefs/.depend, 1: ignoring stale .depend for /usr/obj/usr/src/amd64.amd64/lib/libnetbsd/libnetbsd_pie.a cc -O2 -pipe -fno-common -I/usr/src/usr.sbin/makefs -I/usr/src/sys/fs/cd9660/ -DMAKEFS -I/usr/src/sys/fs/msdosfs -I/usr/src/sbin/newfs_msdos -DHAVE_STRUCT_STAT_ST_FLAGS=1 -I/usr/src/contrib/mtree -I/usr/src/contrib/mknod -I/usr/src/lib/libnetbsd -fPIE -g -std=c11 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -pie -o makefs.full cd9660.o ffs.o makefs.o msdos.o mtree.o walk.o cd9660_strings.o cd9660_debug.o cd9660_eltorito.o cd9660_write.o cd9660_conversion.o iso9660_rrip.o cd9660_archimedes.o ffs_alloc.o ffs_balloc.o ffs_bswap.o ffs_subr.o ufs_bmap.o buf.o mkfs.o ffs_tables.o mkfs_msdos.o msdosfs_conv.o msdosfs_denode.o msdosfs_fat.o msdosfs_lookup.o msdosfs_vnops.o msdosfs_vfsops.o getid.o misc.o spec.o pack_dev.o -L/usr/obj/usr/src/amd64.amd64/lib/libnetbsd -lnetbsd_pie -L/usr/obj/usr/src/amd64.amd64/lib/libutil -lutil -L/usr/obj/usr/src/amd64.amd64/lib/libsbuf -lsbuf ld: error: unable to find library -lnetbsd_pie cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 case 2) https://pastebin.ubuntu.com/p/4mQyK8yrNT/
Sorry,I made a mistake. make should be given inside the folder /usr/src/usr.sbin/bhyve and not inside /usr/src/usr.sbin and the error does not appear.
Keyword: patch or patch-ready – in lieu of summary line prefix: [patch] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=7c85b2342aa2f737ed7c81a83dc510db8f7e172d commit 7c85b2342aa2f737ed7c81a83dc510db8f7e172d Author: Michael Reifenberger <mr@FreeBSD.org> AuthorDate: 2021-04-21 10:38:26 +0000 Commit: Corvin Köhne <corvink@FreeBSD.org> CommitDate: 2022-11-23 09:11:44 +0000 Append Keyboard Layout specified option for using VNC. Part one: supporting QEMU Extended Keyboard Event Message PR: 246121 Submitted by: koinec@yahoo.co.jp Differential Revision: https://reviews.freebsd.org/D29430 (cherry picked from commit b563ff5d4f812df198ade6991834782a5d35af08) usr.sbin/bhyve/console.c | 4 +-- usr.sbin/bhyve/console.h | 4 +-- usr.sbin/bhyve/ps2kbd.c | 54 ++++++++++++++++++++++++++---------- usr.sbin/bhyve/rfb.c | 72 +++++++++++++++++++++++++++++++++++++++++++++++- 4 files changed, 115 insertions(+), 19 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=cc820887ab0ea05c5dcad6d99d9a0d996eb3e19e commit cc820887ab0ea05c5dcad6d99d9a0d996eb3e19e Author: Michael Reifenberger <mr@FreeBSD.org> AuthorDate: 2022-01-20 22:44:04 +0000 Commit: Corvin Köhne <corvink@FreeBSD.org> CommitDate: 2022-11-23 09:11:56 +0000 Append Keyboard Layout specified option for using VNC. Part two: Append bhyve -K option for specified keyboard layout with layout setting files every languages. Since the cmd option '-k' was used in the meantime it was changed to '-K' PR: 246121 Submitted by: koinec@yahoo.co.jp Reviewed by: grehan@ Differential Revision: https://reviews.freebsd.org/D29473 MFC after: 4 weeks (cherry picked from commit 19eaa01beaba68ed4c70c44127955f5c9b331cb9) etc/mtree/BSD.usr.dist | 4 + usr.sbin/bhyve/Makefile | 1 + usr.sbin/bhyve/bhyve.8 | 8 + usr.sbin/bhyve/bhyve_config.5 | 6 + usr.sbin/bhyve/bhyverun.c | 8 +- usr.sbin/bhyve/kbdlayout/Makefile (new) | 40 ++++ usr.sbin/bhyve/kbdlayout/Makefile.depend (new) | 11 + usr.sbin/bhyve/kbdlayout/am (new) | 10 + usr.sbin/bhyve/kbdlayout/be (new) | 45 ++++ usr.sbin/bhyve/kbdlayout/be_acc (new) | 42 ++++ usr.sbin/bhyve/kbdlayout/bg_bds (new) | 10 + usr.sbin/bhyve/kbdlayout/bg_phonetic (new) | 9 + usr.sbin/bhyve/kbdlayout/br (new) | 19 ++ usr.sbin/bhyve/kbdlayout/br_noacc (new) | 22 ++ usr.sbin/bhyve/kbdlayout/centraleuropean (new) | 12 ++ usr.sbin/bhyve/kbdlayout/ch (new) | 36 ++++ usr.sbin/bhyve/kbdlayout/ch-fr (new) | 36 ++++ usr.sbin/bhyve/kbdlayout/ch-fr_acc (new) | 33 +++ usr.sbin/bhyve/kbdlayout/ch_acc (new) | 33 +++ usr.sbin/bhyve/kbdlayout/ch_macbook_acc (new) | 37 ++++ usr.sbin/bhyve/kbdlayout/cz (new) | 11 + usr.sbin/bhyve/kbdlayout/de (new) | 37 ++++ usr.sbin/bhyve/kbdlayout/de_acc (new) | 36 ++++ usr.sbin/bhyve/kbdlayout/de_noacc (new) | 38 ++++ usr.sbin/bhyve/kbdlayout/default (new) | 248 +++++++++++++++++++++++ usr.sbin/bhyve/kbdlayout/dk (new) | 32 +++ usr.sbin/bhyve/kbdlayout/dk_macbook (new) | 35 ++++ usr.sbin/bhyve/kbdlayout/ee (new) | 31 +++ usr.sbin/bhyve/kbdlayout/es (new) | 28 +++ usr.sbin/bhyve/kbdlayout/es_acc (new) | 28 +++ usr.sbin/bhyve/kbdlayout/es_dvorak (new) | 78 +++++++ usr.sbin/bhyve/kbdlayout/fi (new) | 32 +++ usr.sbin/bhyve/kbdlayout/fr (new) | 46 +++++ usr.sbin/bhyve/kbdlayout/fr_acc (new) | 46 +++++ usr.sbin/bhyve/kbdlayout/fr_dvorak (new) | 87 ++++++++ usr.sbin/bhyve/kbdlayout/fr_dvorak_acc (new) | 86 ++++++++ usr.sbin/bhyve/kbdlayout/fr_macbook (new) | 49 +++++ usr.sbin/bhyve/kbdlayout/gr (new) | 9 + usr.sbin/bhyve/kbdlayout/gr_101_acc (new) | 9 + usr.sbin/bhyve/kbdlayout/gr_elot_acc (new) | 17 ++ usr.sbin/bhyve/kbdlayout/hr (new) | 36 ++++ usr.sbin/bhyve/kbdlayout/hu_101 (new) | 9 + usr.sbin/bhyve/kbdlayout/hu_102 (new) | 41 ++++ usr.sbin/bhyve/kbdlayout/is (new) | 33 +++ usr.sbin/bhyve/kbdlayout/is_acc (new) | 32 +++ usr.sbin/bhyve/kbdlayout/it (new) | 34 ++++ usr.sbin/bhyve/kbdlayout/jp (new) | 36 ++++ usr.sbin/bhyve/kbdlayout/jp_capsctrl (new) | 37 ++++ usr.sbin/bhyve/kbdlayout/kz_io (new) | 11 + usr.sbin/bhyve/kbdlayout/kz_kst (new) | 11 + usr.sbin/bhyve/kbdlayout/latinamerican (new) | 33 +++ usr.sbin/bhyve/kbdlayout/latinamerican_acc (new) | 31 +++ usr.sbin/bhyve/kbdlayout/lt (new) | 10 + usr.sbin/bhyve/kbdlayout/nl (new) | 31 +++ usr.sbin/bhyve/kbdlayout/no (new) | 32 +++ usr.sbin/bhyve/kbdlayout/no_dvorak (new) | 81 ++++++++ usr.sbin/bhyve/kbdlayout/nordic_asus-eee (new) | 32 +++ usr.sbin/bhyve/kbdlayout/pl_dvorak (new) | 74 +++++++ usr.sbin/bhyve/kbdlayout/pt (new) | 31 +++ usr.sbin/bhyve/kbdlayout/pt_acc (new) | 28 +++ usr.sbin/bhyve/kbdlayout/ru (new) | 14 ++ usr.sbin/bhyve/kbdlayout/ru_shift (new) | 9 + usr.sbin/bhyve/kbdlayout/ru_win (new) | 9 + usr.sbin/bhyve/kbdlayout/se (new) | 32 +++ usr.sbin/bhyve/kbdlayout/si (new) | 36 ++++ usr.sbin/bhyve/kbdlayout/tr (new) | 36 ++++ usr.sbin/bhyve/kbdlayout/tr_f (new) | 81 ++++++++ usr.sbin/bhyve/kbdlayout/ua (new) | 9 + usr.sbin/bhyve/kbdlayout/ua_shift_alt (new) | 10 + usr.sbin/bhyve/kbdlayout/uk (new) | 14 ++ usr.sbin/bhyve/kbdlayout/uk_capsctrl (new) | 14 ++ usr.sbin/bhyve/kbdlayout/uk_dvorak (new) | 78 +++++++ usr.sbin/bhyve/kbdlayout/uk_macbook (new) | 10 + usr.sbin/bhyve/kbdlayout/us_dvorak (new) | 74 +++++++ usr.sbin/bhyve/kbdlayout/us_dvorakl (new) | 88 ++++++++ usr.sbin/bhyve/kbdlayout/us_dvorakp (new) | 95 +++++++++ usr.sbin/bhyve/kbdlayout/us_dvorakr (new) | 86 ++++++++ usr.sbin/bhyve/kbdlayout/us_dvorakx (new) | 80 ++++++++ usr.sbin/bhyve/kbdlayout/us_emacs (new) | 9 + usr.sbin/bhyve/kbdlayout/us_unix (new) | 14 ++ usr.sbin/bhyve/ps2kbd.c | 95 ++++++++- 81 files changed, 2956 insertions(+), 5 deletions(-)
Is there any chance to have this in 12-STABLE?
(In reply to Michael Osipov from comment #41) Afaik, 12.4 is the last 12.X release and it doesn't accept MFC any more.
(In reply to Corvin Köhne from comment #42) Very sad, 12 will still be supported for more than 1,5 years. At least stable users could have access to this.
Triage: * assignment to a resolving committer * changes/corrections to summary line tagging, and the keyword. (In reply to Michael Osipov from comment #43) For stable/12, the expected end of life is sooner: 2023-12-31. <https://www.freebsd.org/security/#sup> (In reply to Corvin Köhne from comment #42) releng/12.4 <https://www.freebsd.org/releases/12.4R/>, the final release from stable/12, is both: a) frozen; and b) beyond the period during which requests to approve commits were considered. ---- stable/12 remains open, as outlined at <https://www.freebsd.org/releng/#freeze>.
(In reply to Graham Perrin from comment #44) This is news. Seems my source is wrong: https://endoflife.date/freebsd But since 12-STABLE is still open, there is no objective reason not to merge it. Reported: https://github.com/endoflife-date/endoflife.date/issues/1905