[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug 1752646] Re: Freezing VNC screen on some the UEFI framebuffer appli
From: |
Launchpad Bug Tracker |
Subject: |
[Bug 1752646] Re: Freezing VNC screen on some the UEFI framebuffer applications |
Date: |
Sun, 24 Jan 2021 04:17:25 -0000 |
[Expired for QEMU because there has been no activity for 60 days.]
** Changed in: qemu
Status: Incomplete => Expired
--
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:
Expired
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Bug 1752646] Re: Freezing VNC screen on some the UEFI framebuffer applications,
Launchpad Bug Tracker <=