The QEMU project is currently considering to move its bug tracking to another
system. For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state
back to "New" within the next 60 days, otherwise this report will be marked as
"Expired". Or mark it as "Fix Released" if the problem has been solved with a
newer version of QEMU already. Thank you and sorry for the inconvenience.
** Changed in: qemu
Status: New => Incomplete
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1752646
Title:
Freezing VNC screen on some the UEFI framebuffer applications
Status in QEMU:
Incomplete
Bug description:
Hi folks!
I use TianCore (UEFI) formware on the qemu (master version last commit
a6e0344).
When kernel/linux is start, it using UEFI Framebuffer. Then I run UEFI
application (which writes directly to the framebuffer) my VNS screen is
freezing. Then I restart vnclient I see only one frame.
When I run application, I getting in the file hw/display/vga.c on
function 'vga_ioport_write' some commands, it change "s->ar_index"
from 0x20 -> 0x10
In the function vga_update_display:
1751 if (!(s->ar_index & 0x20)) {
1752 graphic_mode = GMODE_BLANK;
1753 } else {
And I got GMODE_BLANK mode. If I patch it:
1751 if (0) {
my VNC not freezing.
From "Hardware Level VGA and SVGA Video Programming Information Page"
I saw, what ar_index is 0x3C0 (Attribute Controller Data Write
Register), 0x20(5-bit) is PAS -- Palette Address Source
If there is a output via the UEFI framebuffer, does the difference
have a PAS or not? Why do we need to pause the output if the PAS is
exposed? Especially when the application outputs via framebuffer.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1752646/+subscriptions
