search

LIS / lis-next

Linux Integration Services
GNU General Public License v2.0
88 stars 51 forks source link

Limitations of the video driver (hyperv_fb.c) in Linux Integration Services #318

Open caschulz88 opened 7 years ago

caschulz88 commented 7 years ago

Hi there,

we are investigating the possibility to use Hyper-V as a base for a new version of one of our products (Browser in the Box). Our goal is to have a Linux VM running on a desktop computer with Hyper-V (Windows 10) with the GUI shown to the user. And we would love to use VMConnect functionality for showing the GUI. The current implementation of the video driver ("hyperv_fb.c"), however, has a number of hard limitations preventing the use of VMConnect for our needs. In particular,

1) The maximum resolution is fixed to 1920x1080. 2) No screen resizing is possible on a running VM (neither from the host side, nor from the VM side itself via "xrandr" or a similar tool).

The question is if those limitations are specific to a particular driver implementation (and can be solved by further extending and modifying the driver) or if they are imposed by the underlying Hyper-V architecture and changes to the Hyper-V code would be necessary to support those features.

We would greatly appreciate if you could give us any information regarding the issues.

In case if the limitations are coming from the driver implementation and the features can be implemented in the Linux Integration Services (without modifying the Hyper-V code), do you maybe know a LIS contributor who would be interested in implementing those features for us (for a certain fee of course)?

Best regards, Clemens A. Schulz

dcui commented 7 years ago

Unluckily, even WS2016 or Win10 doesn't support more than 8MB (see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/video/fbdev/hyperv_fb.c#n64) for framebuffer memory which makes resolutions higher than 1920x1080 impossible.

"I also checked Win10 guest on top of WS2016TP4 and the maximum resolution I was able to set was 1920x1080 too so I think this limitation is for all types of guests, not only Linux"

That being said, we'll ping Hyper-V team if there would be a plan to enlarge the resolution in the future. But even if there would be a plan, I personally don't think it will be implemented in the near future.

caschulz88 commented 7 years ago

Thanks a lot for the quick answer. Is there also something you could comment on the second issue we are faced with or even ping the dev Team for this issue as well and post the response here. Thanke a lot!

dcui commented 7 years ago

I personally guess that screen resizing on a running VM is doable: we need to unregister the current framebuffer from the running Linux kernel, create a new framebuffer, negotiate with the host about the new resolution, and finally register the new framebuffer to the kernel. Of course, I guess the user may notice the change of resolution, e.g. the user may see a flicker of screen, or the resizing of the VM Connect window.

I'll pass the question to the dev team and will keep you updated if I have any response.

dcui commented 7 years ago

Since Windows VM does support dynamic screen resizing, I guess it should be doable for Linux VM, but I don’t know how to query the host about the list of the supported resolutions. I'm asking the Dev team.

dcui commented 7 years ago

Response from the Linux Dev team: " I don't know if Hyper-V team has any future plan to enlarge the framebuffer size. But if the customer thinks reduced color depth is OK for them, we can increase the resolution and with smaller color depth as a tradeoff

All resolutions (width*height) are supported, as long as the framebuffersize is within 8MB. For now, the resolution can be set as kernel cmdline parameters. We need to add a handler for guest Display Settings to be passed to driver, and passed to the host side. "

caschulz88 commented 7 years ago

Hi,

Thank you very much for the answers. I have two more questions on that. Perhaps you could also forward them to the dev team.

1) Increasing resolution and lowering the color depth can be done by simply changing the defines in "hyperv_fb.c". Is this correct? As far as I understand, by default the color depth is set to 32 bits. So by switching to 24 bits we should already be able to support higher resolution, correct?

2) "We need to add a handler for guest Display Settings to be passed to driver, and passed to the host side." Does this has to be only implemented in LIS? Or does the Hyper-V code need to be adapted for this as well?

I guess switching to 24 bits for color depth would be acceptable for us. Switching to 16 bits might be too harsh.

With a 4K screen, which you will find pretty ofter our there in the world nowadays, even with 8bit color depth we would just fit the 8MB framebuffer. So 8MB buffer seems to be very low anyway.

dcui commented 7 years ago

1) Yes, I suppose so, but with this patch (https://github.com/dcui/linux/commit/2cc884f176401930c231a2fa7f01151b5e333453), my VM screen is completely messed up... I'm asking the Dev team about this.

2) We only need to update the LIS. We don't need to change the Hyper-V code.

I personally use VNC to connect to the VM, if I need GUI. With VNC, we can have a very high resolution. :-)

dcui commented 7 years ago

Updates: 24-bit is not supported. It looks only 16-bit and 32-bit are supported.

On Win10 host, we're actually able to use a much higher resolution up to 7680x4320x32 with the help of the Set-VMVideo PowerShell cmdlet , but it looks some non-trivial work is required in the Linux driver to enable this.

FYI: I worked out a proof-of-concept patch, which can successfully enable 2560x1440x32: https://github.com/dcui/linux/commit/c031eec626cd2c41ae1c0e70f51c03284017edf9

caschulz88 commented 7 years ago

This really looks promising!

That would fix the first issue from my initial post of course. So setting this to 4K shouldn't be a problem then - we only need a bug enought buffer there.

The second issue is still open. In one of your first posts you think it should be doable. Did you try it or do you have the knowledge of recreating a framebuffer and switch it with the already running one?! I guess this is how you said it could work.

Thanks for the great support!

dcui commented 7 years ago

I believe the dynamic resolution changing can be supported. However I don't have the enough knowledge to implement that yet, as I'm also busy with other stuff for the time being.

It looks drivers/video/fbdev/hyperv_fb.c: hvfb_set_par() might have already supported dynamic resolution change? I just didn't have a chance to try it.

chvalean commented 7 years ago

@caschulz88 closing this issue based on the recommendations from @dcui Thank you!

libsamek commented 7 years ago

Hi @dcui,

in which kernel version is this available? It would be great if it is packaged for Ubuntu 17.04 :)

dcui commented 7 years ago

@libsamek It turns out more work is needed to push the patch to the upstream. I'll try to find time to further work on this, but I don't think it would be in Ubuntu 17.04, sorry.

mendhak commented 7 years ago

@dcui Just to voice, it would be greatly appreciated; many organisations, including mine, are now implementing Device Guard (Windows 10) which limits virtualization options to HyperV. Being able to work on 2560x1440 as you mentioned would greatly contribute towards productivity.

dcui commented 7 years ago

@mendhak Thanks for the interesting background introduction! Let me see if I can expedite the work.

pcewing commented 6 years ago

Out of curiosity, has this gained any traction? For those that need to use Docker for Windows, having Hyper-V disabled, and thus using VMWare/Virtualbox, isn't an option anymore. There are many developers with 1440p+ monitors that work in Linux VMs either out of preference or necessity and being limited to 1080p is less than ideal.

dcui commented 6 years ago

Thanks for pinging! Now we have a guy working on this and hopefully we'll have some updates in several weeks.

pcewing commented 6 years ago

That's good to hear. Thanks for getting back so soon!

rturpen commented 6 years ago

Can't wait to see 4k linux on hyper-v!!!!! just got bit by win 10 17074 update and device guard...

mfilippov commented 6 years ago

I too wait when it fixed :)

Maaarcocr commented 6 years ago

I can't wait for this. My surface book 2 screen is totally unused by my local VMs!

frankfuu commented 6 years ago

Exciting news!

Fabyao commented 6 years ago

@dcui Thank you for the update!. For the reasons listed by @pcewing I am currently using VMware Workstation 14 Player which does provide dynamic screen resize and supports any resolutions. I thought I would point out that there is an open source project hosted here open-vm-tools. Specifically this point "The ResolutionSet plugin to adjust guest screen resolutions automatically based on window sizes". It might be useful for your dev team to look at?

Jonesb commented 6 years ago

@dcui can you confirm the progress on the this topic? Is dynamic screen resolution likely to be supported in the future without the need for the enhanced session changes and XRDP?

dcui commented 6 years ago

@Jonesb Recently we're working more on Enhanced Session mode support (please read https://blogs.technet.microsoft.com/virtualization/2018/02/28/sneak-peek-taking-a-spin-with-enhanced-linux-vms/) , which would provide a better user experience.

I'll continue to investigate dynamic screen resolution via the hyperv_fb driver. This requires more work, and sorry, I don't have a specific ETA yet..

Jonesb commented 6 years ago

Thanks for the update.

ThomasMcLeod commented 6 years ago

@dcui any update on the display resolution enlargement? I can live with lack of dynamic resizing, but 1080 lines is a deal breaker. We need full 3840x2160 in the guest. What still needs to happen with the https://github.com/dcui/linux/commit/c031eec626cd2c41ae1c0e70f51c03284017edf9 patch. Thanks for all your efforts.

rajivsahu10 commented 5 years ago

any update on this, when can we expect this delivery ?

meschg commented 5 years ago

Vote - Also would love to have this ;)

lixaotec commented 5 years ago

+1

marvincolgin commented 5 years ago

+1.. the limitation of the framebuffer under Hyper-V is an issue for me. As a 25 year Windows developer that is now doing react.js under linux, it's really important for me to be able to work using higher resolution. It's a weird place to be, in which I'm considering making linux my host OS and Windows my guest. eek.

kilves76 commented 4 years ago

So 3rd year of "nothing's been done"...Happy 2020!

That hyperv_fb doesn't accept color depth parameters and because of this greater resolutions cannot be supported. This shouldn't be such a difficult fix?

If only we could specify 2560x1440-16 or 3840x2160-8 as kernel parameters, it'd be more than enough to do actual terminal work with the default 6 console tty's. Especially the latter, giving 4k fullscreen.

rajivsahu10 commented 4 years ago

Yes, I don't know why this hasn't been fixed.

On Wed, Jan 1, 2020, 5:35 PM kilves76 notifications@github.com wrote:

So 3rd year of "nothing's been done"...Happy 2020!

That hyperv_fb doesn't accept color depth parameters and because of this greater resolutions cannot be supported. This shouldn't be such a difficult fix?

If only we could specify 2560x1440-16 or 3840x2160-8 as kernel parameters, it'd be more than enough to do actual terminal work with the default 6 console tty's. Especially the latter, giving 4k fullscreen.

Maybe you could fix the slow scrolling speed issue at the same time, seems hyperv_fb doesn't have a line scroll mode either? The smooth bit scroll is painfully slow, almost like data's being copied instead of screen start pointer being adjusted.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LIS/lis-next/issues/318?email_source=notifications&email_token=ABKHSPJW7QKYM2WWJ4PCPYTQ3SBKFA5CNFSM4DIRPA62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH5D2LQ#issuecomment-570047790, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKHSPJV67XFDMCJMXT6TC3Q3SBKFANCNFSM4DIRPA6Q .

BenjaminWinks commented 4 years ago

The fact that this issue is going into its third year on here is downright shocking - can we get some sort of resolution to this? I can't use this with half my screen being unused, this is unacceptable.

bricelam commented 4 years ago

What ever happened with the plan to use RDP?

bricelam commented 4 years ago

Wrong link. Correct one: https://techcommunity.microsoft.com/t5/virtualization/sneak-peek-taking-a-spin-with-enhanced-linux-vms/ba-p/382415

dcui commented 4 years ago

Sorry, I forgot about this issue... I was wondering why I didn't see some replies in the link https://github.com/LIS/lis-next/issues/655 while I can see the replies via email. :-) Now I realized we actually have 2 different "git-hub issues" (#318 and #655) for the same thing.

Please refer to #655, which has more info about the status. In summary:

  1. Wei Hu has made 2 patches to support higher resolutions, and improve the framebuffer performance on recent Hyper-V hosts, but so far the 2 patches have not been included by any distro or any formal kernel yet.
  2. Wei Hu also has a pending patch to further improve the framebuffer performance of Generation-1 VMs on recent Hyper-V hosts.
  3. Recent Hyper-V hosts will be fixed for the slowness of the synthetic framebuffer, but so far there is no ETA yet (unluckily!)
  4. Before Wei's patches are included into any distro or official kernels, we can work around the slow framebuffer issue by using Generation-2 VM and blacklisting the hyperv_fb driver, since the UEFI framebuffer is fast according to my test; however, I'm not sure if a higher resolution is supported or not.
dcui commented 4 years ago

@bricelam : Thanks for sharing the link! Yes, I think using the Enhanced Session mode can be a good solution (or workaround). BTW, I found a newer post: https://docs.microsoft.com/en-us/virtualization/community/team-blog/2018/20180228-sneak-peek-taking-a-spin-with-enhanced-linux-vms .

It looks this can work fine, since at the bottom of the page of your link, some guy says "This is very useful".

The page of the link I shared says "We encourage you to log any issues you discover to GitHub (https://github.com/microsoft/linux-vm-tools/issues)".

kilves76 commented 4 years ago

There's issues lodged but no replies or resolutions, appears it doesn't work on Ubuntu 19.04 nor 19.10. Instead of "very useful" I see "This repository totally sucks"

dcui commented 4 years ago

@kilves76 : Just now I pinged the team developing Linux Enhance Mode on Hyper-V.

dcui commented 4 years ago

@kilves76 : I got a reply: "There was a breaking change in xrdp that broke the configuration script (See: https://github.com/microsoft/linux-vm-tools/pull/99). A PR has been merged and this should resolve the broken out-of-box experience." As I checked ,the PR was merged yesterday, so it looks that issue will be resolved soon, after the fix is integrated into the distros and images (I hope this won't take too long).

dcui commented 3 years ago

FYI: the slow framebuffer issue has a fix now (see the laetst reply in https://github.com/LIS/lis-next/issues/655)

BTW, Linux VM on Hyper-V is able to support very high resolutions with Wei's patch https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=67e7cdb4829d3246c98f2ec9b771303ebe162eab

It looks this is still true: "No screen resizing is possible on a running VM"

tommck commented 3 years ago

so.... this still seems to be a problem in its FOURTH year

dcui commented 3 years ago

If we use a Gen2 Linux VM with a recent Linux kernel (e.g. v5.5 or newer), we can run 'Set-VMVideo -VMName test1 -HorizontalResolution 7680 -VerticalResolution 4320 -ResolutionType Single' on the host to use a resolution of 7680x4320 for the Linux VM.

If it's a Gen1 Linux VM, the max usuable resolution is lower because the calculated VRAM size mustn't exceed 64MB (this is a bug in Linux hyperv_fb driver, which should be fixed), e.g. (7680 4320 32/8) / (1024.0*1024) = 126.5625, which is > 64, so 7680x4320 does not work, but 3840x4320 works.

"No screen resizing is possible on a running VM" --> this is still not supported by Linux VM, but may be supported in future.

rbreaves commented 2 years ago

I’m going to try this out soon, really need to get 2560x1440 working & possibly 4K in the future.

The enhanced xRDP mode imo is not adequate due to poor input handling via xinput. Makes remapping via anything but xkb an impossible task & xkb in general is such old & fragile code to work w/ it’s just not worth building a detailed & dynamic remapper around (I know because I’ve been there w/ my https://kinto.sh app).

rbreaves commented 2 years ago

@dcui Thank you so much for that!! That perfectly fixed the issue for me! I was trying to do this several months ago and kept seeing the max hard limit of 1920x1080 in hyperv being mentioned everywhere with no realistic alternatives, workarounds or fixes but yes it does appear that on Ubuntu Budgie 21.10 & kernel 5.13 w/ that Gen2 command you mentioned that that fixes the issue perfectly!

Can't thank you enough, this literally makes a very powerful... but somewhat useless Windows computer I recently received very useful! I decided on using HyperV instead of VMware, or virtualbox for various performance reasons and being able to share parts of it out GPU wise, but HyperV's framebuffer limitation for Linux was a real downer.

I can now set what resolution size I may need, granted not dynamic but tbh that is not that big of a deal. I can shut it down and size it easily enough and restart it at any time. Means I do not have to look at Windows at all any more. I can just focus on my work, and on other monitors I do not mind if I have a Windows based web browser running & other things, but my primary OS that I get my work done in always needs to be linux as far as I am concerned.

Set-VMVideo -VMName 'Ubuntu Budgie 21.10' -HorizontalResolution 2736 -VerticalResolution 1724 -ResolutionType Single