Re: Emulate pc speaker in QEMU on MacBook Pro?
Hi Will, >>> >>> is anything (it's an identifier in case you want to have multiple >>> audiodevs). For backend you probably want to use `coreaudio` on a Mac (sdl >>> might be available too, I'm not sure, see the list under the -audiodev >>> option). So something like this: >>> >>> -audiodev coreaudio,id=audio0 -machine pcspk-audiodev=audio0 I expected you have working audio playback with these qemu command line arguments. To exclude a problem with your guest please run 'Day 1 - F-Bird' from the QEMU Advent Calendar 2018. I know this program uses the pc speaker. >>> >>> Thanks, >>> Zoltan >> Hi Zoltan, >> >> Thanks for the hint. I tried it and I didn't get any error, but I also don't >> get any speaker sounds. How do I troubleshoot. I've got the monitor open and >> I don't see any errors. Is coreaudio something native to my mac, or >> something I need to install/configure and is audio0 the usual default >> device? Sorry if this sounds newbieish. >> >> Thanks, >> >> Will > I spoke to soon. As soon as I quit the monitor, an error was displayed: > > coreaudio: Could not lock voice for audioDeviceIOProc > Reason: Invalid argument Did this error message appear after you typed quit in the monitor? Then it's a bug in the qemu coreaudio shutdown routine and you can ignore this message. With best regards, Volker
Re: Emulate pc speaker in QEMU on MacBook Pro?
On 10/8/20 1:18 PM, Will Senn wrote: On 10/8/20 1:01 PM, Volker Rümelin wrote: Hi Will I expected you have working audio playback with these qemu command line arguments. To exclude a problem with your guest please run 'Day 1 - F-Bird' from the QEMU Advent Calendar 2018. I know this program uses the pc speaker. Well, I thought you were pulling my leg, with the greek 'Day 1 - F-Bird' stuff, but a google search led the way to the Advent Calendar, and lo and behold, It works! qemu-system-x86_64 -audiodev coreaudio,id=audio0 -machine pcspk-audiodev=audio0 -fda fbird.com Volker and Zoltan, To wrap this up, fbird.com works in dos and I have sound. So, consider this issue resolved! Thanks for your help and patience. Now, I just gotta figure out what's wrong with my beeping (not bleeping) assembly code :). Will
Re: Emulate pc speaker in QEMU on MacBook Pro?
On 10/8/20 1:01 PM, Volker Rümelin wrote: Hi Will, is anything (it's an identifier in case you want to have multiple audiodevs). For backend you probably want to use `coreaudio` on a Mac (sdl might be available too, I'm not sure, see the list under the -audiodev option). So something like this: -audiodev coreaudio,id=audio0 -machine pcspk-audiodev=audio0 I expected you have working audio playback with these qemu command line arguments. To exclude a problem with your guest please run 'Day 1 - F-Bird' from the QEMU Advent Calendar 2018. I know this program uses the pc speaker. Well, I thought you were pulling my leg, with the greek 'Day 1 - F-Bird' stuff, but a google search led the way to the Advent Calendar, and lo and behold, It works! qemu-system-x86_64 -audiodev coreaudio,id=audio0 -machine pcspk-audiodev=audio0 -fda fbird.com On the dos instance, no joy. Here's my runfile, does it look sane? #!/bin/bash qemu-system-i386 -machine isapc \ -drive file=C.img,format=raw,if=ide,media=disk,readonly=off,index=0,cache=unsafe \ -boot c \ -audiodev coreaudio,id=audio0 -machine pcspk-audiodev=audio0 \ -drive format=raw,file=empty1.img,index=0,if=floppy \ -drive format=raw,file=empty2.img,index=1,if=floppy \ -monitor telnet::,server,nowait -serial mon:stdio & sleep 1 telnet localhost No beeping here. Next thing I'm going to try is running fbird from dos. It's progress! Thanks, Zoltan Hi Zoltan, Thanks for the hint. I tried it and I didn't get any error, but I also don't get any speaker sounds. How do I troubleshoot. I've got the monitor open and I don't see any errors. Is coreaudio something native to my mac, or something I need to install/configure and is audio0 the usual default device? Sorry if this sounds newbieish. Thanks, Will I spoke to soon. As soon as I quit the monitor, an error was displayed: coreaudio: Could not lock voice for audioDeviceIOProc Reason: Invalid argument Did this error message appear after you typed quit in the monitor? Then it's a bug in the qemu coreaudio shutdown routine and you can ignore this message. Yes, it came after. No worries, I'm going to fiddle with this. With best regards, Volker -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
Re: Which qemu change corresponds to RedHat bug 1655408
On 10/8/20 6:49 PM, Jakob Bohm wrote: > (Top posting because previous reply did so): Which previous reply? Mine? I wrote "hi Jakob" then replied in-line, maybe you missed it? See below... > > If the bug was closed as "can't reproduce", why was a very similar bug > listed as fixed in RHSA-2019:2553-01 ? > > > On 2020-10-08 18:41, Philippe Mathieu-Daudé wrote: >> Hi Jakob, >> >> On 10/8/20 6:32 PM, Jakob Bohm wrote: >>> Red Hat bugzilla bug 1655408 against qemu is listed by Red Hat as >>> fixed in >>> April 2019, but I cannot find the corresponding change on qemu.org (the >>> Changelog in the wiki is not a traditional changelog and doesn't cover >>> bugfix releases such as 5.0.1, the git commit log is too detailed to >>> search, the Red Hat bugzilla and security advisory pages do not link >>> red hat bugs back to upstream (launchpad) bugs or git changes. >>> >>> Here is the bug title (which also affects my Debian packaged qemu 5.0): >>> >>> VM can not boot up due to "Failed to lock byte 100" if cdrom has been >>> mounted on the host >>> >>> Further observation: >>> >>> The basic problem is that qemu-system refuses to start with the error >>> message "Failed to lock byte 100" when -drive points to a read-only >>> ISO file. For the reporter of the Red Hat bug, that was a mount-induced >>> read-only condition, in my case it is an NFS mount of a read-only >>> directory. >>> >>> The error message itself seams meaningless, as there is no particular >>> reason to request file locks on a read-only raw disk image. >>> >>> my qemu-system-x86_64 invocation contains the option (on one line): >>> >>> -drive if=none,id=drive-ide0-1-0,readonly=on, >>> file=/mnt/someshare/path/gparted-live-1.1.0-5-amd64.iso,format=raw >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1655408 has been >> closed due to lack of reproducer. Can you amend your information >> to the BZ? It will likely be re-opened. Thanks! ... here is my reply. Regards, Phil. >> >>> >>> Enjoy >>> >>> Jakob >>> -- >>> Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com >>> Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 >>> This public discussion message is non-binding and may contain errors. >>> WiseMo - Remote Service Management for PCs, Phones and Embedded >>> >> > > > Enjoy > > Jakob
Re: Which qemu change corresponds to RedHat bug 1655408
(Top posting because previous reply did so): If the bug was closed as "can't reproduce", why was a very similar bug listed as fixed in RHSA-2019:2553-01 ? On 2020-10-08 18:41, Philippe Mathieu-Daudé wrote: Hi Jakob, On 10/8/20 6:32 PM, Jakob Bohm wrote: Red Hat bugzilla bug 1655408 against qemu is listed by Red Hat as fixed in April 2019, but I cannot find the corresponding change on qemu.org (the Changelog in the wiki is not a traditional changelog and doesn't cover bugfix releases such as 5.0.1, the git commit log is too detailed to search, the Red Hat bugzilla and security advisory pages do not link red hat bugs back to upstream (launchpad) bugs or git changes. Here is the bug title (which also affects my Debian packaged qemu 5.0): VM can not boot up due to "Failed to lock byte 100" if cdrom has been mounted on the host Further observation: The basic problem is that qemu-system refuses to start with the error message "Failed to lock byte 100" when -drive points to a read-only ISO file. For the reporter of the Red Hat bug, that was a mount-induced read-only condition, in my case it is an NFS mount of a read-only directory. The error message itself seams meaningless, as there is no particular reason to request file locks on a read-only raw disk image. my qemu-system-x86_64 invocation contains the option (on one line): -drive if=none,id=drive-ide0-1-0,readonly=on, file=/mnt/someshare/path/gparted-live-1.1.0-5-amd64.iso,format=raw https://bugzilla.redhat.com/show_bug.cgi?id=1655408 has been closed due to lack of reproducer. Can you amend your information to the BZ? It will likely be re-opened. Thanks! Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
Re: Which qemu change corresponds to RedHat bug 1655408
Hi Jakob, On 10/8/20 6:32 PM, Jakob Bohm wrote: > Red Hat bugzilla bug 1655408 against qemu is listed by Red Hat as fixed in > April 2019, but I cannot find the corresponding change on qemu.org (the > Changelog in the wiki is not a traditional changelog and doesn't cover > bugfix releases such as 5.0.1, the git commit log is too detailed to > search, the Red Hat bugzilla and security advisory pages do not link > red hat bugs back to upstream (launchpad) bugs or git changes. > > Here is the bug title (which also affects my Debian packaged qemu 5.0): > > VM can not boot up due to "Failed to lock byte 100" if cdrom has been > mounted on the host > > Further observation: > > The basic problem is that qemu-system refuses to start with the error > message "Failed to lock byte 100" when -drive points to a read-only > ISO file. For the reporter of the Red Hat bug, that was a mount-induced > read-only condition, in my case it is an NFS mount of a read-only > directory. > > The error message itself seams meaningless, as there is no particular > reason to request file locks on a read-only raw disk image. > > my qemu-system-x86_64 invocation contains the option (on one line): > > -drive if=none,id=drive-ide0-1-0,readonly=on, > file=/mnt/someshare/path/gparted-live-1.1.0-5-amd64.iso,format=raw https://bugzilla.redhat.com/show_bug.cgi?id=1655408 has been closed due to lack of reproducer. Can you amend your information to the BZ? It will likely be re-opened. Thanks! > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded >
Which qemu change corresponds to RedHat bug 1655408
Red Hat bugzilla bug 1655408 against qemu is listed by Red Hat as fixed in April 2019, but I cannot find the corresponding change on qemu.org (the Changelog in the wiki is not a traditional changelog and doesn't cover bugfix releases such as 5.0.1, the git commit log is too detailed to search, the Red Hat bugzilla and security advisory pages do not link red hat bugs back to upstream (launchpad) bugs or git changes. Here is the bug title (which also affects my Debian packaged qemu 5.0): VM can not boot up due to "Failed to lock byte 100" if cdrom has been mounted on the host Further observation: The basic problem is that qemu-system refuses to start with the error message "Failed to lock byte 100" when -drive points to a read-only ISO file. For the reporter of the Red Hat bug, that was a mount-induced read-only condition, in my case it is an NFS mount of a read-only directory. The error message itself seams meaningless, as there is no particular reason to request file locks on a read-only raw disk image. my qemu-system-x86_64 invocation contains the option (on one line): -drive if=none,id=drive-ide0-1-0,readonly=on, file=/mnt/someshare/path/gparted-live-1.1.0-5-amd64.iso,format=raw Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
Re: Remap a key
On 10/8/20 3:19 AM, Ottavio Caruso via wrote: On 08/10/2020 00:24, Will Senn wrote: Hi Jakob, I get: sendkey ctrl-break invalid parameter: break Is there a list of valid parameters? It's not in the official documentation but, to get a list of keys, type sendkey [tab]. Awesome, thanks. Maybe ctrl-pause... Will
Re: Remap a key
On 08/10/2020 00:24, Will Senn wrote: Hi Jakob, I get: sendkey ctrl-break invalid parameter: break Is there a list of valid parameters? It's not in the official documentation but, to get a list of keys, type sendkey [tab]. In my qemu monitor: QEMU 5.0.0 monitor - type 'help' for more information (qemu) sendkey 0 1 2 3 4 5 6 7 8 9 a ac_back ac_bookmarks ac_forwardac_home ac_refresh again alt alt_r apostrophe asterisk audiomute audionext audioplay audioprev audiostop b backslash backspace bracket_left bracket_right c calculatorcaps_lock comma compose computer copy ctrl ctrl_r cut d deletedot down e end equal esc f f1f10 f11 f12 f2f3 f4f5f6f7 f8f9find front g grave_accent h help henkanhiragana home i insertj k katakanahiragana kp_0 kp_1 kp_2 kp_3 kp_4 kp_5 kp_6 kp_7 kp_8 kp_9 kp_addkp_comma kp_decimalkp_divide kp_enter kp_equals kp_multiply kp_subtract l left less lfm mail mediaselect menu meta_lmeta_r minus muhenkan n num_lock o open p paste pause pgdn pgup power print props q r ret right ros scroll_lock semicolon shift shift_r slash sleep spc stop sysrq t tab u undo unmapped upv volumedownvolumeup w wake x y yen z -- Ottavio Caruso A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?
