Bug 221074
| Summary: | Hyper V Gen 2 install has no mouse | ||
|---|---|---|---|
| Product: | Base System | Reporter: | scorpionmage |
| Component: | misc | Assignee: | freebsd-virtualization (Nobody) <virtualization> |
| Status: | Closed FIXED | ||
| Severity: | Affects Some People | CC: | bsdic, btrfstor, bugzilla.freebsd, decui, emaste, grahamperrin, lme, lwhsu, michael.adm, sepherosa, stephen.wall, val, weh, whu, wulf, ygy, yklaxds, yuri, yuripv |
| Priority: | --- | ||
| Version: | CURRENT | ||
| Hardware: | amd64 | ||
| OS: | Any | ||
| See Also: | https://reviews.freebsd.org/D38140 | ||
|
Description
scorpionmage
2017-07-28 21:19:29 UTC
(In reply to scorpionmage from comment #0) This is not planned. If you want to use X, use VNC instead. I use tigerVNC daily for the FreeBSD development work and of course firefox :). (In reply to Sepherosa Ziehau from comment #1) So, there will be no mouse working in X for a HyperV Gen 2 VM? (In reply to scorpionmage from comment #2) As I said, no plan for it yet. The Hyper-V console is _not_ suitable for X related stuffs. And again, if you want to use X, use VNC; it is recommended and works quite well on both gen1 and gen2 Hyper-V. (In reply to scorpionmage from comment #2) Well, if you _do_ want to stick w/ using the X on the Hyper-V console, then use gen1 VM, which has an emulated PS2 mouse. I actually don't see gen2 VM buys anything useful for desktop users. (In reply to Sepherosa Ziehau from comment #4) Gen2 VM is based on UEFI and SCSI instead of BIOS and IDE. As a desktop user, I only want to use modern systems, not legacy :) The thought of using emulated IDE drives is terrifying. (VirtualBox emulates NVMe, dammit!) I actually recommend using VcXsrv and SSH X forwarding via PuTTY. I have a little PowerShell script to launch the VM and run X apps from the VM on the Windows desktop: https://github.com/myfreeweb/xvmmgr Still, why exactly is the Hyper-V console "_not_ suitable for X related stuffs"? (In reply to Sepherosa Ziehau from comment #3) Can you please explain why the console is not suitable? Is there a difference between the Gen 1 and Gen 2 consoles? I am not a fan of the VNC option as now I have to get a viewer on my Windows machine as well as manage a different configuration from other Linux VMs. (In reply to Greg V from comment #5) Agree - the modern technologies are the reason. And it also allows the streamlining of configurations across Linux and FreeBSD VMs. It also allows the GPT partitioning scheme which enables creating temporary filesystem VHDXs which are then mounted by UUID and not by controller location. Thanks for the suggestion. I have also tried xrdp, which ran into issues after an update - the port might not have a maintainer. BTW, this is also happening in 12.0 and Current. (In reply to Greg V from comment #5) (In reply to scorpionmage from comment #7) I switched to using xmonad on FreeBSD in the interim, as it lets me use X without a mouse. It does force learning lots of keyboard shortcuts, though, both for the WM and the applications :-( It's sad to see that mouse integration is still not integrated with latest Hyper-V and FreeBSD 12.1. Maybe the "Microsoft <3 FreeBSD" slogan was meant not too serious. Sorry, disregard my last comment. It was written out of frustation. I thought I would load up BSD in a Hyper-v for old time sake. And then the horror on my face as I realized I could only use the keyboard. And then when I search for a workaround, I find this bug report and the fact that it has been so ignorantly brushed aside. I used to be an avid BSD user, then I switched to Linux. You want to know why? This is the exact BSD mentality that made me switch. "No mouse in Hyper-v? Too bad, I don't use it so why should anyone else need to use it, therefore I won't implement it." And you guys wonder why Linux has become so popular? BSD has gone from being one of the greatest to being one of the worst, and a laughing stock. R.I.P. (In reply to Dwerva from comment #12) Hi Dwerva, maybe you can use a Generation-1 FreeBSD VM as a workaround? Mouse works with Gen1 FreeBSD VMs, because Hyper-V emulates a legacy mouse. For Gen-2 VMs, Hyper-V doesn't emulate the legacy mouse, so we have to develop a para-virtualized front-end mouse driver in the VM to use mouse. For Linux VM, the driver is https://github.com/torvalds/linux/blob/master/drivers/hid/hid-hyperv.c. I once tried to port the driver to FreeBSD, but unluckily it turned out I couldn't understand how the mouse APIs work in FreeBSD (I studied the mouse APIs for a few days but still didn't quite understand which sets of API should be used and how the Hyper-V mouse events should be converted to the mouse events that can be understood by FreeBSD) so I gave up... :-( I hope somebody with more knowledge on FreeBSD mouse APIs can help. (In reply to Dexuan Cui from comment #13) > I once tried to port the driver to FreeBSD, but unluckily it > turned out I couldn't understand how the mouse APIs work in FreeBSD Hi Dexuan, could you send me your port? After 13 has got generic HID support, it is probably quite easy to connect the port with mouse/whatever else HID-based API. What is needed are: 1. Standard probe/attach/detach functions. 2. Routine to fetch HID report descriptor. 3. Interrupt control functions: setup/unsetup/start/stop. 4. Interrupt handler capable of reading input report. 5. Get report/Set report/Write output report routines (only if supported). See https://github.com/freebsd/freebsd-src/blob/main/sys/dev/hid/hid_if.m for HID transport backend protocol description. And could someone from Microsoft give some attention to Gen 2 VM keyboard improvement reviews: https://reviews.freebsd.org/D28170 and https://reviews.freebsd.org/D28171 ? (In reply to Vladimir Kondratyev from comment #14) Hi Vladimir, sorry I actually just did some research and didn't write any code. :-) The Hyper-V/VMBus part of the driver should be straightforward, I'm just not familiar with the HID part. The core logic of the Hyper-V mouse driver in Linux VM is Line 296~306 (https://github.com/torvalds/linux/blob/master/drivers/hid/hid-hyperv.c#L296): IIRC, for every mouse event, the Hyper-V host sends a 7-byte "input_report", which in Linux VM is handled by the Linux HID API hid_input_report() and nothing else is done. In FreeBSD, I'm not sure what the equivalent API is? -- I read the page you shared and I guess it may be: METHOD int get_report { device_t dev; void *data; hid_size_t maxlen; hid_size_t *actlen; uint8_t type; uint8_t id; }; I suppose the format of the 7 bytes from the Hyper-V host should comply with the HID spec for mouse (I guess there is a spec for this?), and if so, FreeBSD can use the 7 bytes directly, just like Linux VM does. I'm currently in the middle of something else, so sorry I can't work on this right now. I guess Wei (whu) on our team can help on this, and also review the 2 kbd patches. (In reply to Dexuan Cui from comment #15) > I'm just not familiar with the HID part. And I am not familiar with VMbus :-) > IIRC, for every mouse event, the Hyper-V host sends > a 7-byte "input_report", which in Linux VM is handled > by the Linux HID API hid_input_report() and nothing else is done. > In FreeBSD, I'm not sure what the equivalent API is? intr_handler callback sends input report body to upper layers. See e.g. iichid driver: https://github.com/freebsd/freebsd-src/blob/main/sys/dev/iicbus/iichid.c#L583. The callback is registered with intr_setup method https://github.com/freebsd/freebsd-src/blob/main/sys/dev/hid/hid_if.m#L50. > I suppose the format of the 7 bytes from the Hyper-V host > should comply with the HID spec for mouse As it is not a boot protocol which takes only 3 bytes, it should be prescribed in HID report descriptor. I think it lies in one of the Linux header files. > I guess Wei (whu) on our team can help on this, and also review the 2 kbd patches. That would be great! Thanks! If someone familiar with VMbus would write driver capable to just print these 7 bytes, I would easily connect it to our HID API. (In reply to Vladimir Kondratyev from comment #16) Thanks, Vladimir! Sounds like a good cooperation opportunity! :-) At the expense of the mouse - this is certainly good, but so far no one has fixed the disappearance of the keyboard in the Hyper-V console after a few seconds on the Gen2 VM (it started somewhere in the beginning of 12.0 and at 14.0 the same thing). (In reply to Michael from comment #18) > disappearance of the keyboard in the Hyper-V console after a few seconds on the Gen2 VM Hopefully it is fixed in 14. I added K_XLATE, K_CODE and evdev support to hv_kbd driver recently (In reply to Vladimir Kondratyev from comment #19) I don't see any patch for keyboard disappearing from you in Gen2 VM in current branch 14.0. It is highly desirable to have a normal keyboard in the console, as its disappearance sometimes leads to very undesirable consequences, and is very frustrating. (In reply to Michael from comment #20) Vladimir committed following two on April 12: commit e4643aa4c4ffd385a5be635a488cf10fb6d6cf68 Author: Vladimir Kondratyev <wulf@FreeBSD.org> Date: Mon Apr 12 02:08:36 2021 +0300 hv_kbd: Add support for K_XLATE and K_CODE modes for gen 2 VMs That fixes disabled keyboard input after Xorg server has been stopped. Reviewed by: whu MFC after: 1 month Differential revision: https://reviews.freebsd.org/D28171 commit c2a159286c7694306fde8c161af47a220e1a76f2 Author: Vladimir Kondratyev <wulf@FreeBSD.org> Date: Mon Apr 12 02:07:35 2021 +0300 hv_kbd: Add evdev protocol support for gen 2 VMs Reviewed by: whu MFC after: 1 month Differential revision: https://reviews.freebsd.org/D28170 (In reply to Wei Hu from comment #21) If so, then these patches did not help. I updated the kernel a few days ago - the keyboard in the Hyper-V console disappears anyway after a while of using it. I do not install and use Xorg at all, only the default console. (In reply to Wei Hu from comment #21) I noticed an interesting point. We have only two Gen2 VMs on the hypervisor. We turn on the first VM. The keyboard works for a day or two normally, it does not disappear. We turn on the second VM and run buildworld in it, for example. In the first VM, the keyboard disappears in just a minute. Maybe this will help to identify this nasty bug. (In reply to Michael from comment #23) I also have a Gen2 VM running for a while. I used it to developed a FreeBSD kernel module last year, and I left it running since then. I admit I don't directly use console often. But every time I open the console, the keyboard always works. I will leave the console open for a few days to see if it hit the same problem you are seeing. The VM is at r366933 with some additional changes I made irrelevant to keyboard. So it should has the same problem as you have. In the meantime, if you can problem more information about how to reproduce it, such as the kind of operation you are using on the consoles, and Hyper-V version, it may help. (In reply to Wei Hu from comment #24) Windows Hyper-V 2019 Server 10.0.17763 (KB4586875, KB4494174, KB4523204, KB4539571, KB4549947, KB4558997, KB4561600, KB4562562, KB4580325, KB4587735, KB4592440) All VMs of the Gen2 version (about 10 VMs, the load on the hypervisor is about 50%, 2x Intel Xeon E5-2623 v3). Most FreeBSD 13.0-CURRENT (GENERIC) VMs and two FreeBSD 14.0-CURRENT (GENERIC) VMs have their kernel updated yesterday. All FreeBSD VMs in the Hyper-V console lose their keyboard (there are Linux and Windows VMs - they have everything in order with the keyboard in the Hyper-V console). Another point, I have several hypervisors with approximately the same VM composition and server hardware. And this bug occurs on everyone. Sometimes the FreeBSD VM keyboard disappears even when not using it. (In reply to Michael from comment #25) I forgot to say that all VMs have Mellanox ConnectX-3 and Mellanox ConnectX-4 network cards with SR-IOV enabled (all VMs have network cards with active SR-IOVs). (In reply to Michael from comment #25) Only asking about "keyboard disappears": Do you get detach kernel messages, or is it just unresponsive? The latter may be due to scrollLock state-sync by the HyV-Console-App. If I have no responsive keyboard, toggling ScrolLock fixes it. Also I regularly get CapsLock mismatch between guest and host console - meaning the tty inside the HyperV console has CapsLock active, while notepad on the desk, which runs HyV Console, doesn't behave like CapsLock is active. If I toggle CapLock from inside tty, guest console is totally fine but everything else behaves like CapsLock is active. Might be special side effect caused by RDP (only use RDP to win hosts), never investigated further because it's just a minor issue and isolated to HyV-Console-App. -harry (In reply to Harald Schmalzbauer from comment #27) > Do you get detach kernel messages, or is it just unresponsive? No messages. The keyboard just becomes unresponsive. > The latter may be due to scrollLock state-sync by the HyV-Console-App. > If I have no responsive keyboard, toggling ScrolLock fixes it. Not. Combinations and special keys do not react (you can dance on the keyboard - reactions are zero). In version 13.0, when the keyboard disappears, messages are displayed on the console that occur later, but in 14.0, messages freeze in the place where the keyboard disappeared. At the same time, everything works perfectly over SSH, like the system itself. windows 10 hyper-V 10.0.17763.1 Gen2 FreeBSD 13.0 Now.freebsd 13.0 mouse not work in Hyper-V gen 2,and add sysctl kern.evdev.rcpt_mask=6 the keyboard to work. But mouse still not work. I would like to point out that this is not an X problem, it is a mouse problem. FreeBSD supports a console mouse, allowing cut and paste, on bare metal, and in VirtualBox. Dismissing this support in Hyper-V because "Hyper-V console is not suitable for X" is invalid reasoning. (In reply to Vladimir Kondratyev from comment #16) I have put together a stub hv_ms driver (code copied and modified from hv_kbd). As it is, it does nothing other than spamming the console on mouse events. If this works for you, feel free to "commandeer" the review. https://reviews.freebsd.org/D38140 A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=e4d3f1e40ab3327e4ff6f689f54a64bd2ebc0568 commit e4d3f1e40ab3327e4ff6f689f54a64bd2ebc0568 Author: Yuri <yuri@aetern.org> AuthorDate: 2023-02-05 15:32:08 +0000 Commit: Vladimir Kondratyev <wulf@FreeBSD.org> CommitDate: 2023-02-05 15:32:08 +0000 hv_hid: Hyper-V HID driver Hyper-V HID driver using hidbus/hms. Reviewed by: wulf MFC after: 1 week PR: 221074 Differential revision: https://reviews.freebsd.org/D38140 sys/amd64/conf/NOTES | 1 + sys/conf/files.x86 | 1 + sys/dev/hid/hidbus.c | 1 + sys/dev/hyperv/input/hv_hid.c (new) | 564 ++++++++++++++++++++++++++++++++++ sys/i386/conf/NOTES | 1 + sys/modules/hyperv/Makefile | 2 +- sys/modules/hyperv/hid/Makefile (new) | 12 + 7 files changed, 581 insertions(+), 1 deletion(-) A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=21f4e817fde79d5de79bfbdf180d358ca5f48bf9 commit 21f4e817fde79d5de79bfbdf180d358ca5f48bf9 Author: Yuri <yuri@aetern.org> AuthorDate: 2023-02-05 15:32:08 +0000 Commit: Yuri Pankov <yuripv@FreeBSD.org> CommitDate: 2023-03-31 18:44:04 +0000 hv_hid: Hyper-V HID driver Hyper-V HID driver using hidbus/hms. Reviewed by: wulf MFC after: 1 week PR: 221074 Differential revision: https://reviews.freebsd.org/D38140 (cherry picked from commit e4d3f1e40ab3327e4ff6f689f54a64bd2ebc0568) sys/amd64/conf/NOTES | 1 + sys/conf/files.x86 | 1 + sys/dev/hid/hidbus.c | 1 + sys/dev/hyperv/input/hv_hid.c (new) | 564 ++++++++++++++++++++++++++++++++++ sys/i386/conf/NOTES | 1 + sys/modules/hyperv/Makefile | 2 +- sys/modules/hyperv/hid/Makefile (new) | 12 + 7 files changed, 581 insertions(+), 1 deletion(-) Marking this as fixed for now (sorry it didn't made it to 13.2). |
