Opened 14 years ago

Closed 13 years ago

#994 closed bug (invalid)

no vmware screen refresh in KDL

Reported by: marcusoverhagen Owned by: axeld
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/pre-alpha1
Keywords: Cc: eric.petit@…, umccullough@…
Blocked By: Blocking:
Platform: All


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 and a self build hrev19981.

Change History (11)

comment:1 by axeld, 14 years ago

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).

comment:2 by diver, 14 years ago

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.

in reply to:  1 comment:3 by marcusoverhagen, 14 years ago

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.

comment:4 by marcusoverhagen, 14 years ago

Cc: eric.petit@… added

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 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?

comment:5 by umccullough, 14 years ago

Cc: umccullough@… added

comment:6 by marcusoverhagen, 14 years ago

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

comment:7 by marcusoverhagen, 14 years ago

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.

comment:8 by marcusoverhagen, 14 years ago

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

comment:9 by titer, 14 years ago

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

comment:10 by axeld, 14 years ago

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.

comment:11 by axeld, 13 years ago

Resolution: invalid
Status: newclosed

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.

Note: See TracTickets for help on using tickets.