no vmware screen refresh in KDL

[marcusoverhagen]

Using VMware Player for Linux, the screen (vmware window content) is no longer refreshed once KDL has been entered. I see the initial few lines of the Welcome to kernel debugging land, but every command I enter appears to be ignored, as the screen doesn't change. However, when quitting (suspending?) the vmware session, and reopening it, the modified KDL screen, including the commands that I typed and it's output are visible. Still the screen doesn't change, unless I quit vmware again.

Observed with a hrev19974 build form haikuhost.com and a self build hrev19981.

[axeld]

Have you tried using VESA mode instead of the graphics driver? That might actually help, although I'm not sure how/why (I haven't used VMware yet).

[diver]

I have the same vmware behavior too here on windows. When Haiku goes to kdl i have to move vmware window offscreen to repaint window content. It didn't happend before vmware video driver was included. Also as vmware driver switch to 32bit mode i see lots of flickering everywhere in interface, which is quite annoying.

[marcusoverhagen]

Replying to axeld:

Have you tried using VESA mode instead of the graphics driver? That might actually help, although I'm not sure how/why (I haven't used VMware yet).

When using VESA this problem doesn't occur.

[marcusoverhagen]

This problem seems to be related to MTR attributes when mapping the framebuffer in MapDevice() function in device.c.

When B_MTR_WC (write combining) or no attribute is used, the bug appears. When using B_MTR_UC (uncached), KDL screen refresh is working.

According to ​http://download.intel.com/design/PentiumII/applnots/24442201.pdf uncached is much slower than write combining, but write combining can only be used if the hardware supports it. I don't know about vmware.

And why does no attribute have the same problem as write combining?

Kernel bug? Driver bug?

[marcusoverhagen]

info from IRC:

<ekdahl> same problem here. but after waiting for a while the screen is updated <ekdahl> eg. if i write "teams" in the console, i can see the output after about a minute

[marcusoverhagen]

Problem seems to be caused by the accelerant having it's own update thread that tells vmware when to update the screen, but is suspended in KDL.

I added a workaround to hrev19986, but I'm open for better suggestions.

[marcusoverhagen]

Reverted hrev19986 with hrev19987. The workaround didn't work around as expected, and instead did fallback to vesa mode.

[titer]

I'm not sure what keeps working in KDL - could kernel-side updates through add_timer() fix it?

[axeld]

No, KDL runs with interrupts off, and that also includes timer interrupts. Is it possible to let VMware update the screen automatically again somehow (like in VESA mode)? Another possibility would be to alter kernel/debug/frame_buffer_console.cpp to tell VMware when to update the screen. A cleaner solution to this would be to have a special frame buffer module and have kernel/debug/blue_screen.cpp use that one instead, when the VMware driver is running.

[axeld]

Well, for now, I'd guess this won't be fixed for R1. You'll have to disable on-screen KDL when running on VMware and have the vmware driver installed.