[Qemu-devel] [Bug 922076] [NEW] doesn't clear screen on boot
Public bug reported: When I start Linux in Qemu via "qemu -kernel /vmlinuz ...", opens Qemu window, it shows message "Starting Seabios (version 0.5.1-2010...)", and then Linux writes messages like "Loading, please wait..." on top of previous message! For example, I can see "Loading, please wait...on 0.5.1-2010...)" So, Qemu doesn't clean screan before booting OS. Moreover, when I start Linux via "qemu /disk-image", Qemu shows "Starting Seabios (version 0.5.1-2010...)", then switches to graphical mode, shows GRUB, then switches back to text mode and shows "Starting Seabios" again! And again Linux prints messages on top of Seabios messages, and we see a mix of symbols on screen. Also, I found another bug! I am learning now to write kernels. And I see that operator "*(char *)0xb8000 = 0" in C code of kernel doesn't clean first charaster of screen in Qemu in "-curses" mode! If I want to real clean this charaster, I must type "*(char *)0xb8000 = ' '". I attach a kernel (x86, multiboot) with this bug. Just type "make" (you need gcc) and "qemu -curses -kernel kernel". You will see that screen is not cleared, but kernel tries to clean it. If you change 0 to ' ', all will work! ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/922076 Title: doesn't clear screen on boot Status in QEMU: New Bug description: When I start Linux in Qemu via "qemu -kernel /vmlinuz ...", opens Qemu window, it shows message "Starting Seabios (version 0.5.1-2010...)", and then Linux writes messages like "Loading, please wait..." on top of previous message! For example, I can see "Loading, please wait...on 0.5.1-2010...)" So, Qemu doesn't clean screan before booting OS. Moreover, when I start Linux via "qemu /disk-image", Qemu shows "Starting Seabios (version 0.5.1-2010...)", then switches to graphical mode, shows GRUB, then switches back to text mode and shows "Starting Seabios" again! And again Linux prints messages on top of Seabios messages, and we see a mix of symbols on screen. Also, I found another bug! I am learning now to write kernels. And I see that operator "*(char *)0xb8000 = 0" in C code of kernel doesn't clean first charaster of screen in Qemu in "-curses" mode! If I want to real clean this charaster, I must type "*(char *)0xb8000 = ' '". I attach a kernel (x86, multiboot) with this bug. Just type "make" (you need gcc) and "qemu -curses -kernel kernel". You will see that screen is not cleared, but kernel tries to clean it. If you change 0 to ' ', all will work! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/922076/+subscriptions
[Qemu-devel] [Bug 922076] Re: doesn't clear screen on boot
** Attachment added: "kernel code. this kernel makes qemu bugs visible" https://bugs.launchpad.net/bugs/922076/+attachment/2694574/+files/kernel.tar -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/922076 Title: doesn't clear screen on boot Status in QEMU: New Bug description: When I start Linux in Qemu via "qemu -kernel /vmlinuz ...", opens Qemu window, it shows message "Starting Seabios (version 0.5.1-2010...)", and then Linux writes messages like "Loading, please wait..." on top of previous message! For example, I can see "Loading, please wait...on 0.5.1-2010...)" So, Qemu doesn't clean screan before booting OS. Moreover, when I start Linux via "qemu /disk-image", Qemu shows "Starting Seabios (version 0.5.1-2010...)", then switches to graphical mode, shows GRUB, then switches back to text mode and shows "Starting Seabios" again! And again Linux prints messages on top of Seabios messages, and we see a mix of symbols on screen. Also, I found another bug! I am learning now to write kernels. And I see that operator "*(char *)0xb8000 = 0" in C code of kernel doesn't clean first charaster of screen in Qemu in "-curses" mode! If I want to real clean this charaster, I must type "*(char *)0xb8000 = ' '". I attach a kernel (x86, multiboot) with this bug. Just type "make" (you need gcc) and "qemu -curses -kernel kernel". You will see that screen is not cleared, but kernel tries to clean it. If you change 0 to ' ', all will work! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/922076/+subscriptions
[Qemu-devel] [Bug 922076] Re: doesn't clear screen on boot
** Description changed: - When I start Linux in Qemu via "qemu -kernel /vmlinuz ...", opens Qemu - window, it shows message "Starting Seabios (version 0.5.1-2010...)", and - then Linux writes messages like "Loading, please wait..." on top of + When I start Linux in Qemu via "qemu -kernel /vmlinuz ...", Qemu window + appears and it shows message "Starting Seabios (version 0.5.1-2010...)", + and then Linux writes messages like "Loading, please wait..." on top of previous message! For example, I can see "Loading, please wait...on 0.5.1-2010...)" So, Qemu doesn't clean screan before booting OS. Moreover, when I start Linux via "qemu /disk-image", Qemu shows "Starting Seabios (version 0.5.1-2010...)", then switches to graphical mode, shows GRUB, then switches back to text mode and shows "Starting Seabios" again! And again Linux prints messages on top of Seabios messages, and we see a mix of symbols on screen. Also, I found another bug! I am learning now to write kernels. And I see that operator "*(char *)0xb8000 = 0" in C code of kernel doesn't clean first charaster of screen in Qemu in "-curses" mode! If I want to real clean this charaster, I must type "*(char *)0xb8000 = ' '". I attach a kernel (x86, multiboot) with this bug. Just type "make" (you need gcc) and "qemu -curses -kernel kernel". You will see that screen is not cleared, but kernel tries to clean it. If you change 0 to ' ', all will work! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/922076 Title: doesn't clear screen on boot Status in QEMU: New Bug description: When I start Linux in Qemu via "qemu -kernel /vmlinuz ...", Qemu window appears and it shows message "Starting Seabios (version 0.5.1-2010...)", and then Linux writes messages like "Loading, please wait..." on top of previous message! For example, I can see "Loading, please wait...on 0.5.1-2010...)" So, Qemu doesn't clean screan before booting OS. Moreover, when I start Linux via "qemu /disk-image", Qemu shows "Starting Seabios (version 0.5.1-2010...)", then switches to graphical mode, shows GRUB, then switches back to text mode and shows "Starting Seabios" again! And again Linux prints messages on top of Seabios messages, and we see a mix of symbols on screen. Also, I found another bug! I am learning now to write kernels. And I see that operator "*(char *)0xb8000 = 0" in C code of kernel doesn't clean first charaster of screen in Qemu in "-curses" mode! If I want to real clean this charaster, I must type "*(char *)0xb8000 = ' '". I attach a kernel (x86, multiboot) with this bug. Just type "make" (you need gcc) and "qemu -curses -kernel kernel". You will see that screen is not cleared, but kernel tries to clean it. If you change 0 to ' ', all will work! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/922076/+subscriptions
[Qemu-devel] [Bug 1162227] Re: Mouse works badly when connecting to host via vnc
** Description changed: Let's assume we have some physical host A. This host runs qemu guest B locally without any options like "-vnc" etc. Then I connect from some physical host C to the host A via VNC or Teamviewer ( www.teamviewer.com ). And then I try to remote control (via this vnc connection) qemu guest. But I cannot do this because my mouse disappears when I click at my qemu guest. I see little black square only. (This square is vnc feature, it automatically appears when mouse disappears.) When I click to some objects inside guest I will instead click to another random object inside guest. I saw this bug in the following configurations: - * A: Debian squeeze 64-bit, Teamviewer 8, Qemu 0.12.5, C: Ubuntu precise 64-bit, Teamviewer 8, B: Windows 7 32-bit, command line: + * A: Debian squeeze 64-bit, Teamviewer 8, Qemu 1.1.2, C: Ubuntu precise 64-bit, Teamviewer 8, B: Windows 7 32-bit, command line: qemu-system-x86_64 --enable-kvm -m 2048 -daemonize -localtime -drive cache=none,file=/root/vm/w7-sp1-i386-en.cow - * A: Debian squeeze 64-bit, Teamviewer 8, Qemu 0.12.5, C: Ubuntu precise 64-bit, Teamviewer 8, B: Debian squeeze 64-bit, command line: + * A: Debian squeeze 64-bit, Teamviewer 8, Qemu 1.1.2, C: Ubuntu precise 64-bit, Teamviewer 8, B: Debian squeeze 64-bit, command line: qemu-system-x86_64 -enable-kvm -m 256 -daemonize -snapshot -net none -drive cache=none,file=/dev/sda - * A: Debian squeeze 64-bit, x11vnc 0.9.10, Qemu 0.12.5, C: Ubuntu precise 64-bit, xvnc4viewer 4.1.1, B: Windows 7 32-bit, command line: + * A: Debian squeeze 64-bit, x11vnc 0.9.10, Qemu 1.1.2, C: Ubuntu precise 64-bit, xvnc4viewer 4.1.1, B: Windows 7 32-bit, command line: qemu-system-x86_64 --enable-kvm -m 2048 -daemonize -localtime -drive cache=none,file=/root/vm/w7-sp1-i386-en.cow Also, if I add "-usbdevice tablet" option, this bug will disappear. So, probably, this bug is not a bug. But in this case you should document it. I. e. you should add to docs something like "add -usbdevice tablet if you remote control qemu host". Also, if I use "-vnc" option (in the text above I didn't use it!) my mouse doesn't work as expected, too. The pointers don't line up, i. e. are not synced. But if I add "-usbdevice tablet" option, mouse will work. As far as I know this is not a bug. But then document it, too. Qemu's man page already says "It is very useful to enable the usb tablet - device when using this option (option -usbdevice tablet)" in qemu - 0.12.5. But I think this is not enough. The man page should say: "You - should add -usbdevice tablet option and your guest OS should support - tablet device or your mouse will not work". + device when using this option (option -usbdevice tablet)" in qemu 1.1.2. + But I think this is not enough. The man page should say: "You should add + -usbdevice tablet option and your guest OS should support tablet device + or your mouse will not work". -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1162227 Title: Mouse works badly when connecting to host via vnc Status in QEMU: New Bug description: Let's assume we have some physical host A. This host runs qemu guest B locally without any options like "-vnc" etc. Then I connect from some physical host C to the host A via VNC or Teamviewer ( www.teamviewer.com ). And then I try to remote control (via this vnc connection) qemu guest. But I cannot do this because my mouse disappears when I click at my qemu guest. I see little black square only. (This square is vnc feature, it automatically appears when mouse disappears.) When I click to some objects inside guest I will instead click to another random object inside guest. I saw this bug in the following configurations: * A: Debian squeeze 64-bit, Teamviewer 8, Qemu 1.1.2, C: Ubuntu precise 64-bit, Teamviewer 8, B: Windows 7 32-bit, command line: qemu-system-x86_64 --enable-kvm -m 2048 -daemonize -localtime -drive cache=none,file=/root/vm/w7-sp1-i386-en.cow * A: Debian squeeze 64-bit, Teamviewer 8, Qemu 1.1.2, C: Ubuntu precise 64-bit, Teamviewer 8, B: Debian squeeze 64-bit, command line: qemu-system-x86_64 -enable-kvm -m 256 -daemonize -snapshot -net none -drive cache=none,file=/dev/sda * A: Debian squeeze 64-bit, x11vnc 0.9.10, Qemu 1.1.2, C: Ubuntu precise 64-bit, xvnc4viewer 4.1.1, B: Windows 7 32-bit, command line: qemu-system-x86_64 --enable-kvm -m 2048 -daemonize -localtime -drive cache=none,file=/root/vm/w7-sp1-i386-en.cow Also, if I add "-usbdevice tablet" option, this bug will disappear. So, probably, this bug is not a bug. But in this case you should document it. I. e. you should add to docs something like "add -usbdevice tablet if you remote control qemu host". Also, if I use "-vnc" option (in the text above I didn't use it!) my mouse doesn't work as expected, too. The pointers don't line up, i. e.
[Qemu-devel] [Bug 1162227] [NEW] Mouse works badly when connecting to host via vnc
Public bug reported: Let's assume we have some physical host A. This host runs qemu guest B locally without any options like "-vnc" etc. Then I connect from some physical host C to the host A via VNC or Teamviewer ( www.teamviewer.com ). And then I try to remote control (via this vnc connection) qemu guest. But I cannot do this because my mouse disappears when I click at my qemu guest. I see little black square only. (This square is vnc feature, it automatically appears when mouse disappears.) When I click to some objects inside guest I will instead click to another random object inside guest. I saw this bug in the following configurations: * A: Debian squeeze 64-bit, Teamviewer 8, Qemu 0.12.5, C: Ubuntu precise 64-bit, Teamviewer 8, B: Windows 7 32-bit, command line: qemu-system-x86_64 --enable-kvm -m 2048 -daemonize -localtime -drive cache=none,file=/root/vm/w7-sp1-i386-en.cow * A: Debian squeeze 64-bit, Teamviewer 8, Qemu 0.12.5, C: Ubuntu precise 64-bit, Teamviewer 8, B: Debian squeeze 64-bit, command line: qemu-system-x86_64 -enable-kvm -m 256 -daemonize -snapshot -net none -drive cache=none,file=/dev/sda * A: Debian squeeze 64-bit, x11vnc 0.9.10, Qemu 0.12.5, C: Ubuntu precise 64-bit, xvnc4viewer 4.1.1, B: Windows 7 32-bit, command line: qemu-system-x86_64 --enable-kvm -m 2048 -daemonize -localtime -drive cache=none,file=/root/vm/w7-sp1-i386-en.cow Also, if I add "-usbdevice tablet" option, this bug will disappear. So, probably, this bug is not a bug. But in this case you should document it. I. e. you should add to docs something like "add -usbdevice tablet if you remote control qemu host". Also, if I use "-vnc" option (in the text above I didn't use it!) my mouse doesn't work as expected, too. The pointers don't line up, i. e. are not synced. But if I add "-usbdevice tablet" option, mouse will work. As far as I know this is not a bug. But then document it, too. Qemu's man page already says "It is very useful to enable the usb tablet device when using this option (option -usbdevice tablet)" in qemu 0.12.5. But I think this is not enough. The man page should say: "You should add -usbdevice tablet option and your guest OS should support tablet device or your mouse will not work". ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1162227 Title: Mouse works badly when connecting to host via vnc Status in QEMU: New Bug description: Let's assume we have some physical host A. This host runs qemu guest B locally without any options like "-vnc" etc. Then I connect from some physical host C to the host A via VNC or Teamviewer ( www.teamviewer.com ). And then I try to remote control (via this vnc connection) qemu guest. But I cannot do this because my mouse disappears when I click at my qemu guest. I see little black square only. (This square is vnc feature, it automatically appears when mouse disappears.) When I click to some objects inside guest I will instead click to another random object inside guest. I saw this bug in the following configurations: * A: Debian squeeze 64-bit, Teamviewer 8, Qemu 0.12.5, C: Ubuntu precise 64-bit, Teamviewer 8, B: Windows 7 32-bit, command line: qemu-system-x86_64 --enable-kvm -m 2048 -daemonize -localtime -drive cache=none,file=/root/vm/w7-sp1-i386-en.cow * A: Debian squeeze 64-bit, Teamviewer 8, Qemu 0.12.5, C: Ubuntu precise 64-bit, Teamviewer 8, B: Debian squeeze 64-bit, command line: qemu-system-x86_64 -enable-kvm -m 256 -daemonize -snapshot -net none -drive cache=none,file=/dev/sda * A: Debian squeeze 64-bit, x11vnc 0.9.10, Qemu 0.12.5, C: Ubuntu precise 64-bit, xvnc4viewer 4.1.1, B: Windows 7 32-bit, command line: qemu-system-x86_64 --enable-kvm -m 2048 -daemonize -localtime -drive cache=none,file=/root/vm/w7-sp1-i386-en.cow Also, if I add "-usbdevice tablet" option, this bug will disappear. So, probably, this bug is not a bug. But in this case you should document it. I. e. you should add to docs something like "add -usbdevice tablet if you remote control qemu host". Also, if I use "-vnc" option (in the text above I didn't use it!) my mouse doesn't work as expected, too. The pointers don't line up, i. e. are not synced. But if I add "-usbdevice tablet" option, mouse will work. As far as I know this is not a bug. But then document it, too. Qemu's man page already says "It is very useful to enable the usb tablet device when using this option (option -usbdevice tablet)" in qemu 0.12.5. But I think this is not enough. The man page should say: "You should add -usbdevice tablet option and your guest OS should support tablet device or your mouse will not work". To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1162227/+subscriptions
[Qemu-devel] [Bug 1162227] Re: Mouse works badly when connecting to host via vnc
I tried to reproduce this bug using lastest stable version (1.4.0) and master (5e3a0f418c4d57399778cee0b55aebfb663b6425). This versions seem to add "-usbdevice tablet" by default (and this is very good). But I think that if guest OS doesn't support tablet device then bug will still appear. So, I added option "-usbdevice mouse" to simulate this situation. And bug really appeared (i. e. mouse disappeared). So, please fix it or document it. Configurations: * A: Ubuntu precise 64-bit, x11vnc 0.9.12, Qemu 1.4.0, C: Debian squeeze 64-bit, xvnc4viewer 4.1.1, B: Ubuntu precise 64-bit, command line: /opt/qemu-1.4.0/bin/qemu-system-x86_64 -enable-kvm -m 256 -daemonize -snapshot -drive cache=none,file=/dev/sda -net none -usbdevice mouse * A: Ubuntu precise 64-bit, x11vnc 0.9.12, Qemu 5e3a0f418c4d57399778cee0b55aebfb663b6425, C: Debian squeeze 64-bit, xvnc4viewer 4.1.1, B: Ubuntu precise 64-bit, command line: /opt/qemu-5e3a0f418c4d57399778cee0b55aebfb663b6425/bin/qemu-system-x86_64 -enable-kvm -m 256 -daemonize -snapshot -drive cache=none,file=/dev/sda -net none -usbdevice mouse Same for -vnc option (i. e. pointers was not synced when using -usbdevice mouse) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1162227 Title: Mouse works badly when connecting to host via vnc Status in QEMU: New Bug description: Let's assume we have some physical host A. This host runs qemu guest B locally without any options like "-vnc" etc. Then I connect from some physical host C to the host A via VNC or Teamviewer ( www.teamviewer.com ). And then I try to remote control (via this vnc connection) qemu guest. But I cannot do this because my mouse disappears when I click at my qemu guest. I see little black square only. (This square is vnc feature, it automatically appears when mouse disappears.) When I click to some objects inside guest I will instead click to another random object inside guest. I saw this bug in the following configurations: * A: Debian squeeze 64-bit, Teamviewer 8, Qemu 1.1.2, C: Ubuntu precise 64-bit, Teamviewer 8, B: Windows 7 32-bit, command line: qemu-system-x86_64 --enable-kvm -m 2048 -daemonize -localtime -drive cache=none,file=/root/vm/w7-sp1-i386-en.cow * A: Debian squeeze 64-bit, Teamviewer 8, Qemu 1.1.2, C: Ubuntu precise 64-bit, Teamviewer 8, B: Debian squeeze 64-bit, command line: qemu-system-x86_64 -enable-kvm -m 256 -daemonize -snapshot -net none -drive cache=none,file=/dev/sda * A: Debian squeeze 64-bit, x11vnc 0.9.10, Qemu 1.1.2, C: Ubuntu precise 64-bit, xvnc4viewer 4.1.1, B: Windows 7 32-bit, command line: qemu-system-x86_64 --enable-kvm -m 2048 -daemonize -localtime -drive cache=none,file=/root/vm/w7-sp1-i386-en.cow Also, if I add "-usbdevice tablet" option, this bug will disappear. So, probably, this bug is not a bug. But in this case you should document it. I. e. you should add to docs something like "add -usbdevice tablet if you remote control qemu host". Also, if I use "-vnc" option (in the text above I didn't use it!) my mouse doesn't work as expected, too. The pointers don't line up, i. e. are not synced. But if I add "-usbdevice tablet" option, mouse will work. As far as I know this is not a bug. But then document it, too. Qemu's man page already says "It is very useful to enable the usb tablet device when using this option (option -usbdevice tablet)" in qemu 1.1.2. But I think this is not enough. The man page should say: "You should add -usbdevice tablet option and your guest OS should support tablet device or your mouse will not work". To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1162227/+subscriptions
[Qemu-devel] [Bug 922076] Re: doesn't clear screen on boot
UPDATE: The second bug (which is started with "Also, I found another bug! I am learning...") is fixed in 1.4.0 About the first bug: screen clears on real hardware, so it is really bug. Also, it is reproducible with Qemu 1.4.0 and Qemu 5e3a0f418c4d57399778cee0b55aebfb663b6425. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/922076 Title: doesn't clear screen on boot Status in QEMU: New Bug description: When I start Linux in Qemu via "qemu -kernel /vmlinuz ...", opens Qemu window, it shows message "Starting Seabios (version 0.5.1-2010...)", and then Linux writes messages like "Loading, please wait..." on top of previous message! For example, I can see "Loading, please wait...on 0.5.1-2010...)" So, Qemu doesn't clean screan before booting OS. Moreover, when I start Linux via "qemu /disk-image", Qemu shows "Starting Seabios (version 0.5.1-2010...)", then switches to graphical mode, shows GRUB, then switches back to text mode and shows "Starting Seabios" again! And again Linux prints messages on top of Seabios messages, and we see a mix of symbols on screen. Also, I found another bug! I am learning now to write kernels. And I see that operator "*(char *)0xb8000 = 0" in C code of kernel doesn't clean first charaster of screen in Qemu in "-curses" mode! If I want to real clean this charaster, I must type "*(char *)0xb8000 = ' '". I attach a kernel (x86, multiboot) with this bug. Just type "make" (you need gcc) and "qemu -curses -kernel kernel". You will see that screen is not cleared, but kernel tries to clean it. If you change 0 to ' ', all will work! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/922076/+subscriptions
[Qemu-devel] [Bug 922076] Re: doesn't clear screen on boot
And this is Screenshot_20161216_005917.png . Here (after grub) we see "recovering journal" on top of seabios string ** Attachment added: "Screenshot_20161216_005917.png" https://bugs.launchpad.net/qemu/+bug/922076/+attachment/4792206/+files/Screenshot_20161216_005917.png -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/922076 Title: doesn't clear screen on boot Status in QEMU: Incomplete Bug description: When I start Linux in Qemu via "qemu -kernel /vmlinuz ...", Qemu window appears and it shows message "Starting Seabios (version 0.5.1-2010...)", and then Linux writes messages like "Loading, please wait..." on top of previous message! For example, I can see "Loading, please wait...on 0.5.1-2010...)" So, Qemu doesn't clean screan before booting OS. Moreover, when I start Linux via "qemu /disk-image", Qemu shows "Starting Seabios (version 0.5.1-2010...)", then switches to graphical mode, shows GRUB, then switches back to text mode and shows "Starting Seabios" again! And again Linux prints messages on top of Seabios messages, and we see a mix of symbols on screen. Also, I found another bug! I am learning now to write kernels. And I see that operator "*(char *)0xb8000 = 0" in C code of kernel doesn't clean first charaster of screen in Qemu in "-curses" mode! If I want to real clean this charaster, I must type "*(char *)0xb8000 = ' '". I attach a kernel (x86, multiboot) with this bug. Just type "make" (you need gcc) and "qemu -curses -kernel kernel". You will see that screen is not cleared, but kernel tries to clean it. If you change 0 to ' ', all will work! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/922076/+subscriptions
[Qemu-devel] [Bug 922076] Re: doesn't clear screen on boot
This is Screenshot_20161216_005859.png , screenshot with grub ** Attachment added: "Screenshot_20161216_005859.png" https://bugs.launchpad.net/qemu/+bug/922076/+attachment/4792205/+files/Screenshot_20161216_005859.png -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/922076 Title: doesn't clear screen on boot Status in QEMU: Incomplete Bug description: When I start Linux in Qemu via "qemu -kernel /vmlinuz ...", Qemu window appears and it shows message "Starting Seabios (version 0.5.1-2010...)", and then Linux writes messages like "Loading, please wait..." on top of previous message! For example, I can see "Loading, please wait...on 0.5.1-2010...)" So, Qemu doesn't clean screan before booting OS. Moreover, when I start Linux via "qemu /disk-image", Qemu shows "Starting Seabios (version 0.5.1-2010...)", then switches to graphical mode, shows GRUB, then switches back to text mode and shows "Starting Seabios" again! And again Linux prints messages on top of Seabios messages, and we see a mix of symbols on screen. Also, I found another bug! I am learning now to write kernels. And I see that operator "*(char *)0xb8000 = 0" in C code of kernel doesn't clean first charaster of screen in Qemu in "-curses" mode! If I want to real clean this charaster, I must type "*(char *)0xb8000 = ' '". I attach a kernel (x86, multiboot) with this bug. Just type "make" (you need gcc) and "qemu -curses -kernel kernel". You will see that screen is not cleared, but kernel tries to clean it. If you change 0 to ' ', all will work! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/922076/+subscriptions
[Qemu-devel] [Bug 922076] Re: doesn't clear screen on boot
The bug still exists in qemu 2.7 (version present in my debian stretch). I was not able reproduce the bug with booting kernel directly with 2.7 (-kernel ...), but booting disk image causes the bug. So, I have debian gnu/linux stretch amd64. debian package qemu- system-x86 1:2.7+dfsg-3+b1. I run my host system in qemu (i. e. I run in qemu same system that running on the host) using well known "-snapshot -drive file=/dev/sda" trick. Precise command line is: kdesudo -c "exec qemu-system-x86_64 -m 1024M -enable-kvm -daemonize -snapshot -drive file=/dev/sda,cache=none,format=raw" Qemu appears and I see usual "SeaBIOS (version 1.9.3-20161025_171302-gandalf)" as you can see at screenshot Screenshot_20161216_005817.png . Then qemu switches to grub. And then qemu switches to text mode back. And fsck prints to console: "/dev/sda2: recovering journal", but this words appears on top of that SeaBIOS self-adver., so we have the following words mixture: /dev/sda2: recovering journal25_171302-gandalf) I use sdl. I don't know build option, this is qemu from debian package ** Attachment added: "Screenshot_20161216_005817.png" https://bugs.launchpad.net/qemu/+bug/922076/+attachment/4792204/+files/Screenshot_20161216_005817.png -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/922076 Title: doesn't clear screen on boot Status in QEMU: Incomplete Bug description: When I start Linux in Qemu via "qemu -kernel /vmlinuz ...", Qemu window appears and it shows message "Starting Seabios (version 0.5.1-2010...)", and then Linux writes messages like "Loading, please wait..." on top of previous message! For example, I can see "Loading, please wait...on 0.5.1-2010...)" So, Qemu doesn't clean screan before booting OS. Moreover, when I start Linux via "qemu /disk-image", Qemu shows "Starting Seabios (version 0.5.1-2010...)", then switches to graphical mode, shows GRUB, then switches back to text mode and shows "Starting Seabios" again! And again Linux prints messages on top of Seabios messages, and we see a mix of symbols on screen. Also, I found another bug! I am learning now to write kernels. And I see that operator "*(char *)0xb8000 = 0" in C code of kernel doesn't clean first charaster of screen in Qemu in "-curses" mode! If I want to real clean this charaster, I must type "*(char *)0xb8000 = ' '". I attach a kernel (x86, multiboot) with this bug. Just type "make" (you need gcc) and "qemu -curses -kernel kernel". You will see that screen is not cleared, but kernel tries to clean it. If you change 0 to ' ', all will work! To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/922076/+subscriptions
[Qemu-devel] [Bug 1425597] Re: moving window + changing screen resolution = bug
The bug is not present in Qemu 2.12 (version reported by dpkg: qemu- system-x86 1:2.12+dfsg-1+b1). There is similar minor bug instead. The new bug doesn't harm me and I am not even sure is this a bug. So, this is info about new minor bug. Host is Debian Sid installed today (23 May MSK) with mentioned Qemu 2.12. I run Qemu in X using: # qemu-system-x86_64 -m 1024 -daemonize -snapshot -drive file=/dev/sda,format=raw,cache=none -kernel /boot/vmlinuz* -initrd /boot/initrd* -append root=/dev/sda Then I started to move Qemu window using mouse. I kept Qemu window catched by my mouse while guest OS boot. At some moment guest OS (Linux) switched from text mode to framebuffer. Internal screen resolution changed, but Qemu window didn't change its size (I kept moving Qemu window all this time), but likely window content didn't scale (this is as opposed to 3d30395f [3d30395f7fb3315e4ecf0de4e48790e1326bbd47] behavior, 3d30395f scaled window content). So text in window remain concrete (not fluid, as opposed to 3d30395f). Then I tried to resize Qemu window and window size imidiately became normal, i. e. it started to fit content. All this is acceptable for me. I. e. I see this is nothing wrong when Qemu cannot change its window size when I move Qemu window -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1425597 Title: moving window + changing screen resolution = bug Status in QEMU: Incomplete Bug description: Steps to reproduce: 1. Run qemu (sdl) 2. Start moving the window 3. At that moment the virtualized OS should change its screen resolution (for example, when switching from initial qemu screen to grub) What I see: Window size doesn't change, but internal screen resolution changes, so, image scale stops to be 1:1, now I see virtualized OS in wrong scale. What I expected to see: Window size changes so, that it keeps synchronized with internal resolution (as usual) This bug preserves at lastest git version at the moment, i. e. 3d30395f7fb3315e4ecf0de4e48790e1326bbd47 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1425597/+subscriptions
