[Qemu-devel] [Bug 932490] [NEW] Qemu fails on -fda /dev/fd0 when no medium is present

2012-02-14 Thread Herbert Poetzl 
Public bug reported:

# qemu-system-x86_64 --version
QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice 
Bellard

# qemu-system-x86_64 -fda /dev/fd0
qemu-system-x86_64: -fda /dev/fd0: could not open disk image /dev/fd0: No such 
device or address

Starting with a medium (floppy disk) inserted, then removing or changing
the medium works fine.

** 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/932490

Title:
  Qemu fails on -fda /dev/fd0 when no medium is present

Status in QEMU:
  New

Bug description:
  # qemu-system-x86_64 --version
  QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice 
Bellard

  # qemu-system-x86_64 -fda /dev/fd0
  qemu-system-x86_64: -fda /dev/fd0: could not open disk image /dev/fd0: No 
such device or address

  Starting with a medium (floppy disk) inserted, then removing or
  changing the medium works fine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/932490/+subscriptions

Re: [Qemu-devel] Linux 2.6.10 ?

2005-05-08 Thread Herbert Poetzl 
On Sun, May 08, 2005 at 08:24:57AM +0200, Der Herr Hofrat wrote:
> 
> Hi !
> 
>  does anybody have a 2.6.X (preferably 2.6.10) running under qemu ?
>  trying to launch it (passed with -kernel) fails - it simply gives me

works fine here with and without graphical output
for using qemu-fast x86/x86 you might want to look
at the following patches/configs:

 http://vserver.13thfloor.at/Stuff/QEMU/

HTH,
Herbert

>  (qemu)
> 
>  thats it - the 2.6.10 is compiled as generic 686 and works fine on the box
> 
> thx !
> 
> Nicholas Mc Guire   e-mail: [EMAIL PROTECTED]
> OpenTech EDV-Research GmbH  Embedded GNU/Linux/RTLinux
> Lichtenstein Str. 31 2130 Mistelbachweb   :http://www.opentech.at/
> phone :+43 2572 201082  fax   :+43 2572 201084
> 
> news: 7th Real Time Linux Workshop, 2-4 Nov 2004, Lille France -  details at 
>   http://www.realtimelinuxfoundation.org/events/events.html soon
> 
> 
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] booting linux 2.6 in qemu-system-ppc

2005-05-16 Thread Herbert Poetzl 
On Sun, May 15, 2005 at 02:07:48AM +0200, Johannes Berg wrote:
> Hi,
> 
> Just for the record: if I remove the VGA card from the qemu pci bus I
> can successfully boot a linux 2.6 kernel with serial console. Apparently
> there's something wrong with it.

wrong with what? linux 2.6? the vga card? the serial
console? your kernel config? 

> If you want to discuss please CC me.

best,
Herbert

> johannes



> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [Patch] target-ppc mtcrf instruction not recognized

2005-05-18 Thread Herbert Poetzl 
On Tue, May 17, 2005 at 11:10:52PM +0200, J. Mayer wrote:
> 
> I will implement the new form, so it most crf transfers can be
> optimized.
> 
> The latest PowerPC specification is to be found here:
> 
> 
> 

you sure about that?

best,
Herbert

> -- 
> J. Mayer <[EMAIL PROTECTED]>
> Never organized
> 
> 
> 
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] [patch] gcc4 host support

2005-05-18 Thread Herbert Poetzl 
On Tue, May 17, 2005 at 09:46:30PM +0100, Paul Brook wrote:
> On Monday 16 May 2005 10:41, David Woodhouse wrote:
> > On Wed, 2005-05-11 at 22:04 +0100, Paul Brook wrote:
> > > My solution is to search the function for the "ret" instruction and
> > > replace them with a jmp to the next block of code. On RISC targets this
> > > would be easy.
> >
> > About this easy, in fact...
> >...
> > +
> > +   if (get32((uint32_t *)p) == 0x4e800020) {
> > +   blr_addr = p;
> > +   copy_size = p_end - p_start;
> > +   break;
> > +   }
> 
> You probably want to scan the whole function to check there aren't multiple 
> blr instructions, and throw an error if there are.

hmm, wouldn't it be much easier to separate compiling
from assembling, and do the 'changes' on the assembler
files instead?

just an idea ...

best,
Herbert

> Other than that it looks ok to me.
> 
> Paul
> 
> 
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Building qemu on UltraSparc

2005-05-21 Thread Herbert Poetzl 
On Sat, May 21, 2005 at 07:32:11PM +0200, Jérôme Warnier wrote:
> I'm trying to build qEmu v0.7.0 on Debian Sarge on a Sparc64 machine,
> and it fails with strange errors.
> Does anybody here have any idea to help me achieve it?

well, looks like you hit 32 vs 64 bit issues here, don't know
the details about the sparc/64 support but I'd try to build
as sparc32 first and see how far that gets ...

HTH,
Herbert

> I attach the log of the build to this mail.
> 
> Thanks

> dpkg-buildpackage: source package is qemu
> dpkg-buildpackage: source version is 0.7.0-0bxlug0
> dpkg-buildpackage: source maintainer is Jerome Warnier <[EMAIL PROTECTED]>
> dpkg-buildpackage: host architecture is sparc
>  fakeroot debian/rules clean
> test -x debian/rules
> test "`id -u`" = 0
> if test -n "" && test "" != "."; then rmdir ""; fi
> if test "." != "."; then rmdir .; fi
> dh_clean
> /usr/bin/make -f debian/rules reverse-config
> make[1]: Entering directory `/home/jwarnier/debian/qemu-0.7.0'
> make[1]: Nothing to be done for `reverse-config'.
> make[1]: Leaving directory `/home/jwarnier/debian/qemu-0.7.0'
> patches: debian/patches/01_doc_typos.patch 
> debian/patches/03_use_external_bios.patch 
> debian/patches/04_do_not_print_rtc_freq_if_ok.patch
> Not reversing not applied patches.
> if [ "reverse-patches" = "debian/stamp-patched" ] ; then touch 
> debian/stamp-patched ; \
> elif [ "reverse-patches" = "reverse-patches" ] ; then rm -f 
> debian/stamp-patch* ; \
> fi
> /usr/bin/make -f debian/rules update-config
> make[1]: Entering directory `/home/jwarnier/debian/qemu-0.7.0'
> make[1]: Nothing to be done for `update-config'.
> make[1]: Leaving directory `/home/jwarnier/debian/qemu-0.7.0'
> rm -f debian/patches/*.log
> make -C . -k distclean || true
> make[1]: Entering directory `/home/jwarnier/debian/qemu-0.7.0'
> rm -f config.mak config.h op-i386.h opc-i386.h gen-op-i386.h op-arm.h 
> opc-arm.h gen-op-arm.h 
> rm -f *.o *.a qemu-img dyngen TAGS *.pod *~ */*~
> make -C tests clean
> make[2]: Entering directory `/home/jwarnier/debian/qemu-0.7.0/tests'
> rm -f *~ *.o test-i386.out test-i386.ref \
>test-x86_64.log test-x86_64.ref qruncom sha1
> make[2]: Leaving directory `/home/jwarnier/debian/qemu-0.7.0/tests'
> for d in ; do \
> make -C $d clean || exit 1 ; \
> done
> rm -f config-host.mak config-host.h
> for d in ; do \
> rm -rf $d || exit 1 ; \
> done
> make[1]: Leaving directory `/home/jwarnier/debian/qemu-0.7.0'
> rm -f debian/stamp-makefile-build
> if [ -f "./config.log" ] && grep -i 'generated.*by.*autoconf' "./config.log" 
> 1>/dev/null; then \
>   rm -f "./config.log"; \
> fi
> rm -f debian/stamp-autotools-files
> if test -f ./config.status && grep -i -q 'Generated.*by configure.' 
> ./config.status; then rm -f ./config.status; fi
> if test -f ./config.cache && grep -i -q 
> 'shell.*script.*caches.*results.*configure' ./config.cache; then rm -f 
> ./config.cache; fi
> rm -f qemu-doc.html qemu.1
> rm -f 
> rm -f pc-bios/*.elf pc-bios/*.tar.gz
>  dpkg-source -b qemu-0.7.0
> dpkg-source: building qemu using existing qemu_0.7.0.orig.tar.gz
> dpkg-source: building qemu in qemu_0.7.0-0bxlug0.diff.gz
> dpkg-source: warning: ignoring deletion of file pc-bios/bios.bin
> dpkg-source: warning: ignoring deletion of file pc-bios/ppc_rom.bin
> dpkg-source: warning: ignoring deletion of file pc-bios/proll.elf
> dpkg-source: warning: ignoring deletion of file pc-bios/vgabios-cirrus.bin
> dpkg-source: warning: ignoring deletion of file pc-bios/vgabios.bin
> dpkg-source: warning: ignoring deletion of file qemu-doc.html
> dpkg-source: warning: ignoring deletion of file qemu.1
> dpkg-source: building qemu in qemu_0.7.0-0bxlug0.dsc
>  debian/rules build
> test -x debian/rules
> if [ -n "" ]; then \
>   mkdir -p ""; \
> fi
> if [ ! -d "." ]; then \
>   mkdir -p "."; \
> fi
> /usr/share/cdbs/1/rules/buildcore.mk:116: "DEB_BUILD_MAKE_TARGET is a 
> deprecated variable"
> /usr/share/cdbs/1/rules/buildcore.mk:116: "DEB_CLEAN_MAKE_TARGET is a 
> deprecated variable"
> /usr/share/cdbs/1/rules/buildcore.mk:116: "DEB_MAKE_TEST_TARGET is a 
> deprecated variable"
> if [ -z "" ]; then \
>   if ! test -f debian/compat; then echo 4 > debian/compat; fi; \
> fi
> /usr/bin/make -f debian/rules reverse-config
> make[1]: Entering directory `/home/jwarnier/debian/qemu-0.7.0'
> make[1]: Nothing to be done for `reverse-config'.
> make[1]: Leaving directory `/home/jwarnier/debian/qemu-0.7.0'
> patches: debian/patches/01_doc_typos.patch 
> debian/patches/03_use_external_bios.patch 
> debian/patches/04_do_not_print_rtc_freq_if_ok.patch
> Trying patch debian/patches/01_doc_typos.patch at level 1...1...success.
> Trying patch debian/patches/03_use_external_bios.patch at level 
> 1...1...success.
> Trying patch debian/patches/04_do_not_print_rtc_freq_if_ok.patch at level 
> 1...1...success.
> if [ "debian/stamp-patched" = "debian/stamp-patched" ] ; then touch 
> debian/stamp-patched ; \
> elif [ "debian/stamp-patched" = "reverse-patches" ]

Re: [Qemu-devel] Qemu sandbox for teaching

2005-05-29 Thread Herbert Poetzl 
On Sat, May 28, 2005 at 07:50:53PM +0200, Jerome Warnier wrote:
> Le samedi 28 mai 2005 à 14:13 +0100, Paul Brook a écrit :
> > On Saturday 28 May 2005 13:42, Jerome Warnier wrote:
> > > Does someone here have an idea on how to do the following using Qemu,
> > > but I'm open to other suggestions:
> > >
> > > I would like to provide a UNIX CLI sandbox for users to poke around in a
> > > UNIX course. It would be better if available from the web (preferably
> > > without having to install anything on the users' PC), and Free (as in
> > > free speach).
> > > The problem is that I need to give them root access, or at least a
> > > simulation.
> > > It would be even better if we could for instance install RedHat in it,
> > > but it's not really required.
> > 
> > It's not really answering your question, but qemu is probably OTT for this. 
> > If 
> > I was setting this up I'd use UML and a java web based telnet/ssh client.
> Well, I was thinking about what the snapshot feature of qemu could bring
> me.
> 
> In fact, I thought about the following solutions:
> - qemu (or whatever other virtualization system)
> - chroot (or specifically dchroot in Debian) and remote telnet or ssh
> access
> - UML
> 
> Advantages of every solution:
> - qemu virtualizes a complete machine, which means installation of an OS
> is possible and it is pretty safe (security-wise) to setup
> - chroot is fast to run and pretty safe
> - UML is fast to run and pretty safe
> 
> Problems of every solution:
> - qemu is slow, and a lot of virtual machines at the same time on the
> same machine will slow it down and use too much memory, I think (I'm
> talking about 10 people «playing» at the same time). Using only a
> text-mode virtual machine may probably help, though
> - chroot does not allow much and may take time to setup correctly
> - UML is difficult to setup, and needs a kernel patch (even on 2.6?) to

you might want to have a look at linux-vserver

http://linux-vserver.org/

it allows you to have VPS with certain root rights
on a shared host, in a secure manner (no overhead)

HTH,
Herbert

> work
> 
> 
> > Paul
> -- 
> Jerome Warnier <[EMAIL PROTECTED]>
> BeezNest
> 
> 
> 
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Hand written code generator #2

2005-06-01 Thread Herbert Poetzl 
On Wed, Jun 01, 2005 at 07:40:33AM +0200, Jens Arm wrote:
> Hi Paul
> 
> I get a compile errorif I try with latest qemu cvs:
> 
> ../dyngen -o op.h op.o
> ../dyngen -c -o opc.h op.o
> gcc -Wall -O2 -g -fno-strict-aliasing -fomit-frame-pointer -I. 
> -I/home/tux/tmp/qemu/target-sparc -I/home/tux/tmp/qemu 
> -I/home/tux/tmp/qemu/host-i386 -I/home/tux/tmp/qemu/linux-user 
> -I/home/tux/tmp/qemu/linux-user/sparc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
> -D_LARGEFILE_SOURCE -I/home/tux/tmp/qemu/fpu -I/home/tux/tmp/qemu/slirp -c -o 
> translate-op.o /home/tux/tmp/qemu/translate-op.c
> make[1]: *** Keine Regel vorhanden, um das Target »qregs.def«, 
>   benötigt von »translate-qop.o«, zu erstellen.  Schluss.
> make[1]: Leaving directory `/home/tux/tmp/qemu/sparc-user'
> make: *** [all] Fehler 1

if you are more comfortable with a localized error message,
that's probably fine, but for postings to an english spoken 
ml you should really use LANG=C LC_ALL=C 

best,
Herbert

> Jens
> 
> On Tue, 31 May 2005 16:23:28 +0100
> Paul Brook <[EMAIL PROTECTED]> wrote:
> 
> > I've made available a new version of my hand-written code generator for 
> > qemu. 
> > The patch is getting rather large, so I've put it on a web server to avoid 
> > spamming the list:
> > https://nowt.dyndns.org/patch.qemu_qop.gz
> > 
> > In principle it's very similar to the previous patch. The main difference 
> > is 
> > that it now supports all target architectures, including 64-bit targets.
> > 
> > The i386 changes have been tested by booting knoppix and win2k and win98.
> > x86-64 tested by booting a debian amd64 install cd.
> > ppc chanages tested by booting a debina install cd and running nbench under 
> > ppc-user.
> > My sparc debian cd doesn't boot under qemu (stops responding just after 
> > loading the kernel). Does anyone have any images I could use for testing 
> > sparc emulation?
> > 
> > To support 64-bit targets each qreg now has a "mode" which determines its 
> > size. 64-bit qregs can be implemented using pairs of host registers on 
> > 32-bit 
> > hosts, or single registers on 64-bit hosts.
> > 
> > ppc and sparc targets only have nominal support. I've done the bare minimum 
> > needed to make them work. Arm is still the only target that really takes 
> > advantage of any of the new functionality.
> > 
> > Next on my todo list is support for ppc and x86-64 hosts.
> > 
> > Paul
> > 
> > 
> > ___
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> > 
> 
> 
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: Re: [Qemu-devel] Re: xen is not working with qemu0.7/kqemu

2005-06-14 Thread Herbert Poetzl 
On Mon, Jun 13, 2005 at 10:49:56AM -0400, Ben Taylor wrote:
> > From: Ishwar Rattan <[EMAIL PROTECTED]> wrote:
> >
> > 
> > Why would anyone want run an emulator in another emulator..
> 
> because, AFAIK, xen doesn't run windows under a linux host
> with xen.  Using qemu/kqemu, you could (assuming it actually
> works) run a windows session under qemu in a xen session.

just for the record, xen is a virtual machine monitor,
not an emulator, and strictly speaking, neither is QEMU
(which is a hybrid of binary translator and harware
 simulator)

> If qemu with the kqemu module can run under xen, this
> alleviates part of the pressure of getting xen to run
> windows under a linux host.

but of course, it will also kill the good performance
xen could have with a windows support (which already
worked, but is very unlikely to work in the future, as
it requires M$ to adapt their OS to the xen architecture)

best,
Herbert

> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Norton Ghost crashes with page fault for me too.

2005-06-14 Thread Herbert Poetzl 
On Tue, Jun 14, 2005 at 01:51:10PM -0500, [EMAIL PROTECTED] wrote:
> From: "Henrik Nordstrom"
> 
> 
> >> The best that many can do is test qemu and report problems when they are
> >> found.
> >
> > Then you have to accept that the developers do the best they can in their 
> > interest for the benefit of all.
> 
> Generally, the way open source works is that a bug that directly effects a 
> developer, gets fixed.  They get annoyed enough they stop what they are 
> doing and fix it.
> 
> A bug that directly effects code they have written, might get checked into.
> 
> If it's a bug they can live with or work around, it doesn't get fixed.  And 
> probably not reported, for that matter.
> 
> If it's a bug that effects an OS that they don't use, it gets ignored. 
> (Hence, the Windows builds were broken for a long time and nobody noticed it 
> or if they did notice, didn't bother to fix it.)

well, sounds sane to me, or do you fix your
neighbors broken kitchen sink, just because
you heard him complain about it, instead of
fixing your own?

> >> But that's no excuse for bug reports to just vanish into the void. 
> >> Without
> >> an awknowledgement or somebody writting it down as a bug in qemu that 
> >> needs
> >> to get fixed eventually.
> >
> > There rarely is a void these days. If you send a bug report to a public 
> > mailinglist then it
> 
> That makes the very very large assumption that the developers deliberately 
> go looking through the back message archives for bugs that haven't been 
> fixed.

if there _are_ good reasons for them to do
so, they'll probably do it ...

> After a couple days, people just forget about reported bugs.

and real bugs pop up again and again ... which
is a very good method to filter real bugs from
coincidential issues ...

> >   b) Other people later having the same problem quite likely finds it in 
> > the archives and refers to it when reporting the same issue again if it 
> > still isn't fixed.
> 
> Similar bugs can show up in different ways.
> 
> Even when a bug does show up repeatedly, and effects many people, doesn't 
> mean anybody cares to look into it.

so?

> It just turns into one of those consistant bugs that everybody knows about 
> but no longer think of as a bug.  It becomes a 'feature' or a 'quirk'. 
> "It's just the way qemu does things" kind of mental shift.
> 
> The cd changing bugs are excellent examples.
> 
> They've been around for so long that most people in here no longer even 
> think of them as bugs.  They are just simply quirks in qemu.  And because 
> they are no longer 'bugs' but 'quirks', nobody even thinks to look into it.
> 
> Never mind whether they would find the bug or be able to fix it.  It's been 
> around so long that they don't even *think* of it as a bug anymore, so they 
> don't even *think* to look at it.
> 
> (I"m not saying the cd changing bugs are absolutely critical.  Yes, it does 
> prevent some OS's from being installed!  But it doesn't crash qemu, etc.  It 
> does show how a bug can stop being thought of as a bug.)

if somebody cares enough, s/he will fix it or
make sure that it gets fixed ... whining is
probably the worst way to achieve this ...

> > So even if there is no official bugtracking tool (which depending on the 
> > developer situation can be good or bad) the report isn't really lost.
> 
> Technically, yes, it does get archived.
> 
> But effectively it gets lost because it's no longer immediately visible as a 
> bug.  You have to specifically go looking for bug reports through the 
> archives.  And then go looking through the messages again to see if it's 
> been fixed.  (Either partially or fully.)
> 
> 
> Mailing lists can be very convenient.
> 
> But they also make it easy for things to get essentially lost.  If something 
> isn't in a recent message, then your brain just tends to forget about it 
> after a few days.

you are free to collect and prepare the bug
reports for them, just create your own page
with a list of (for you or others) relevant
bugs and possible fixes/workarounds. I'm pretty
confident the developers will make good use of
this page (if you do the collecting part) and
a bunch of issues will get fixed pretty fast ...

ah, and don't forget to announce it on the ML

best,
Herbert

> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] quick gtk2.c update

2005-06-21 Thread Herbert Poetzl 
On Tue, Jun 21, 2005 at 05:45:12PM -0500, [EMAIL PROTECTED] wrote:
> "Jim C. Brown"
> > I disagree. I think distributing the GTK library with qemu (even for 
> > windows
> > versions) is a very bad idea. At most, the qemu installer should just 
> > download
> > and run the GTK installer. At most.
> 
> It's a very bad idea to have the installer need to go back on to the net to 
> download something else.
> 
> The user should get the whole thing at once.

yes, that's what hyperlinks are for, just put _another_ one
on the download site saying something like: "this also 
requires that you install bla, bla and bla. you can get
a recent version of them here, here and here" ...

> > GTK libraries are not part of qemu, they are a separate resource that qemu
> > depends on.
> 
> As far as the user is concerned, they are part of qemu.

as is VBRUN.dll for each and every application .. NOT!

this is the windows concept of 'do not share libraries',
'do not trust installed resources' and 'do not keep any
compatibility' ...

> > qemu is 3.4M here. So I don't think that is so bad. Especially when that 
> > one
> 
> It shouldn't be.
> 
> There isn't that much conceptually different between windows and linux that 
> should cause it to be that big.
> 
> 
> > set of 6M libs can be shared by many different applications (qemu, xchat, 
> > etc).
> 
> Not under windows, it wont be.
> 
> For us Windows users, qemu will be the only program we use that will need 
> gtk libs.
> 
> Realistically, we don't need GTK.  We've already got a GUI with an api. 
> That's what windows programmers use.  The vast majority of us will never use 
> xchat etc.  Qemu may be the only one they use.

so why not make a native GUI for windows, and just
use that? (according to Micro$oft this could not take
longer than a five minutes with their advanced tools)

> And it's not a good idea to distribute the libraries seperately.

it's neither smart nor good to deploy apps bundled
with a complete operating system. period.

> Or put them in the Windows system directory.  Too much junk gets put there 
> already due to years and years of poor programming, careless authors, 
> indifferent programmers, and Microsoft's encouragement.

precisely, and every app wants to use their 'personal'
version of lib whatever, but that's a windows issue,
nothing which should concern QEMU ...

> >> As for the gui... Well, I haven't seen that yet.  What little I see looks
> >> the same boring Windows window that qemu always runs in.  The gtk version
> >> isn't usable yet.
> 
> > The GTK version, on Linux, is perfectly usable. It is no more usable than 
> > the
> > SDL version, but no less.
> 
> But it's not usable on Windows yet.
> 
> As I said, so far, I'm not seeing *any* gui.  Even the keyboard is messed 
> up, so you can't even use the guest OS.
> 
> 
> > On Windows, you have no fullscreen support. Everything else should be 
> > exactly
> > the same. If it's not, I'll try to fix it.
> 
> I never use full screen, myself.
> 
> I much prefer a window.  Preferably one that's resizable, scroll bars, etc. 
> etc.
> 
> >> It runs, but there are keyboard problems.
> >>
> >
> > What keyboard problems? There shouldn't be any for the GTK version.
> 
> As I said in the other message (which I may have accidently sent directly to 
> you, instead of the list)
> 
> It's not doing the regular US keyboard.  At least it doesn't eappear to be.
> 
> I can get symbols, a few letters, but not the whole thing.  And none of it
> is normal.  Press '1' to get 'n' and so on.
> 
> However, it doesn't appear that the -k keyboard option works for the windows
> version.
> 
> I tried my builds and the official 0.70 build and they don't accept it
> either.
> 
> I tried -k fr -k de -k en-us and so on, and they don't recognise it.
> 
> (I've never tried the -k option before, but according to the docs, it isn't 
> needed for Windows builds.  So it may not be enabled.)
> 
> So, assuming the problem is that gtk can't recognise I'm using a US
> keyboard, I can't do anything to force it.

best,
Herbert


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] make qemu use tap0 instead of tun0

2005-07-06 Thread Herbert Poetzl 
On Wed, Jul 06, 2005 at 07:08:42PM -0400, Jim C. Brown wrote:
> When in tuntap mode, qemu creates a tap device with names like tun0, tun1,
> etc. which seems to confuse some users (the smart ones who ask why qemu uses
> IP frames instead of ethernet frames ... or something along those lines).
> Theses should be named tap0, tap1, etc. This patch fixes qemu.
> 
> I don't think this would break anything (correct qemu-ifup scripts shouldn't
> care about the name of the tuntap device that qemu uses).
> 
> -- 
> Infinite complexity begets infinite beauty.
> Infinite precision begets infinite perfection.

> --- vl.c.1Wed Jul  6 19:03:45 2005
> +++ vl.c  Wed Jul  6 19:04:23 2005
> @@ -1629,7 +1629,7 @@
>  }
>  memset(&ifr, 0, sizeof(ifr));
>  ifr.ifr_flags = IFF_TAP | IFF_NO_PI;
> -pstrcpy(ifr.ifr_name, IFNAMSIZ, "tun%d");
> +pstrcpy(ifr.ifr_name, IFNAMSIZ, "tap%d");
>  ret = ioctl(fd, TUNSETIFF, (void *) &ifr);
>  if (ret != 0) {
>  fprintf(stderr, "warning: could not configure /dev/net/tun: no 
> virtual network emulation\n");

1.1 What is the TUN ?
 The TUN is Virtual Point-to-Point network device.
 TUN driver was designed as low level kernel support for
 IP tunneling. It provides to userland application
 two interfaces:
   - /dev/tunX - character device;
   - tunX - virtual Point-to-Point interface.

 Userland application can write IP frame to /dev/tunX
 and kernel will receive this frame from tunX interface.
 In the same time every frame that kernel writes to tunX
 interface can be read by userland application from /dev/tunX
 device.

1.2 What is the TAP ?
 The TAP is a Virtual Ethernet network device.
 TAP driver was designed as low level kernel support for
 Ethernet tunneling. It provides to userland application
 two interfaces:
   - /dev/tapX - character device;
   - tapX - virtual Ethernet interface.

 Userland application can write Ethernet frame to /dev/tapX
 and kernel will receive this frame from tapX interface.
 In the same time every frame that kernel writes to tapX
 interface can be read by userland application from /dev/tapX
 device.

(from http://vtun.sourceforge.net/tun/faq.html)

best,
Herbert

> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] scrollable window

2005-07-10 Thread Herbert Poetzl 
On Sun, Jul 10, 2005 at 11:37:07AM -0500, [EMAIL PROTECTED] wrote:
> "Jim C. Brown"
> 
> 
> >I personally feel that a scrollable window is not very useful unless your 
> >host
> > resolution is smaller than your guest resolution. Hard to see what the 
> > point is
> 
> Or the same size.  Don't forget, Windows XP will cover up part of the window 
> even when the GTK version switches to 'full screen'.
> 
> And a lot of times, guest resolution will be higher.  Some things just seem 
> to expect 1024x768 or 1280x1024 (or whatever) resolution.
> 
> A scrollable window is just a nice fall back if nothing else is convenient.
> 
> Sometimes, full screen is just too darn inconvenient.  Personally, I can't 
> stand full screen even with VMWare.  I like being able to easily access my 
> desktop when I want to, be able to read some data and type it into the 
> guest, and so on.  (Without having to switch screens back and forth)
> 
> Not everybody in the world uses a 128x1024 screen.  Or even 1024x768.
> 
> Some, such as myself, still use 800x600.  I do it out of necessity.  I have 
> poor eyesight and don't have the spare cash (or desk space!) for a 21 inch 
> monitor.  And LCD monitors tend to have too high a native resolution.  With 
> my current 17" monitor, I simply can't handle anything beyond 800x600.

why not use a virtual desktop of larger size and 
pan the mouse to the current 'view' which can be 800x600
or even less if your bad eyesight requires that ...
(on X you can change that with CTRL-ALT-+/- and the
mouse will be handled properly, including pan ranges)

best,
Herbert

> So, a scrollable window makes using qemu (or vmware) more convenient.
> 
> Sure, scaling the window so the guest thinks it's 1024x768 (or whatever) 
> when it's really much smaller, is probably a better choice.  As would be the 
> video card providing custom sizes (700x400, or whatever) so XP will think 
> that's what the display really is, and the actual qemu/vmware window 
> wouldn't have to be scrolled, scaled or even full screened.
> 
> But scroll windows are a good 'if nothing else works' kind of situation for 
> most people, and useful for some of us.
> 
> 
> 
> > Anyways, this is a version of gtk2.c which gives the wanted scrolling 
> > feature.
> > I just started on this so expect ease-of-use bugs. :D Should work on 
> > windows
> > as well, but I have not been able to test this myself yet.
> 
> Unfortunately, I can't test it for you on a Windows host.
> 
> A bit of a long story, but at the moment, I'm stuck with a single hard drive 
> and cd burner.  I can't access my second hard drive, which is where qemu and 
> my test OS images are stored.
> 
> Sorry.
> 
> 
> 
> 
> 
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] scrollable window

2005-07-10 Thread Herbert Poetzl 
On Sun, Jul 10, 2005 at 01:57:57PM -0400, Jim C. Brown wrote:
> On Sun, Jul 10, 2005 at 07:32:01PM +0200, Herbert Poetzl wrote:
> > > Some, such as myself, still use 800x600.  I do it out of necessity.  I 
> > > have 
> > > poor eyesight and don't have the spare cash (or desk space!) for a 21 
> > > inch 
> > > monitor.  And LCD monitors tend to have too high a native resolution.  
> > > With 
> > > my current 17" monitor, I simply can't handle anything beyond 800x600.
> > 
> > why not use a virtual desktop of larger size and 
> > pan the mouse to the current 'view' which can be 800x600
> > or even less if your bad eyesight requires that ...
> > (on X you can change that with CTRL-ALT-+/- and the
> > mouse will be handled properly, including pan ranges)
> > 
> > best,
> > Herbert
> 
> That works too. So Herbert, tell us how does one set up a virtual screen
> a la X Server style when one is using Windows? Presumably there is some
> "powertoy" out there which does this, but I don't know of any myself.

well, cygwin supports X, which probably gives you
all that and more ...  

actually, never bothered with windows ...

there are a bunch of good solutions for MacOS X too
(like Virtue or DesktopManager)

> -- 
> Infinite complexity begets infinite beauty.
> Infinite precision begets infinite perfection.
> 
> 
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] scrollable window

2005-07-10 Thread Herbert Poetzl 
On Sun, Jul 10, 2005 at 02:53:23PM -0400, Jim C. Brown wrote:
> On Sun, Jul 10, 2005 at 08:37:18PM +0200, Herbert Poetzl wrote:
> > > That works too. So Herbert, tell us how does one set up a virtual screen
> > > a la X Server style when one is using Windows? Presumably there is some
> > > "powertoy" out there which does this, but I don't know of any myself.
> > 
> > well, cygwin supports X, which probably gives you
> > all that and more ...  
> > 
> 
> I was not aware that cygwin supported a virtual screen. It certainly doesn't
> do that in multiwindow mode (the most popular cygwin/x mode).
> 
> > actually, never bothered with windows ...
> 
> I believe he was asking with regards to Windows, as well as in general. So,
> not greatly helpful.

well, I just _assumed_ that the 'almighty' windows
supports something similar (as it really isn't a new
feature) and I don't think that reinventing the panning
inside a qemu gui would be the way to go ...

OTOH, open office did reinvent the workspace too, and
I guess that was inspired by the MS pendant ... so
maybe that's the 'windows' way to handle this after
all ...

best,
Herbert

> -- 
> Infinite complexity begets infinite beauty.
> Infinite precision begets infinite perfection.


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Re: Solaris/SPARC binaries

2005-08-01 Thread Herbert Poetzl 
On Fri, Jul 29, 2005 at 10:05:14AM +0200, Blue Swirl wrote:
> Hi,
> 
> Sparc V8 system emulator is very much complete, but in practice some hidden 
> bugs in it (and also bugs in Proll's Openprom support) make the emulator 
> fragile. It can only run Linux 2.6 series, 2.4 or BSDs won't run. Probably 
> some heavy debugging could make a difference, but it seems that general 
> interest for the emulator is low.

well, just to let you know ... I'm interested in the emulator
(is there some howto available, regarding openprom and such?)

TIA,
Herbert

> I haven't tried Solaris for Sparc V8, it would be interesting to hear the 
> results.
> 
> V9 emulation is getting better, but it's still not usable for anything yet. 
> For example, support for execution in memory above >4G limit (in 32-bit 
> host) was committed to CVS only a few days ago. Maybe the user mode 
> emulator could run 64-bit Linux binaries, but I don't have any.
> 
> It might be possible to make a Solaris user mode emulator by translating 
> Solaris system calls to Linux, but it could be a lot of work.
> 
> _
> Express yourself instantly with MSN Messenger! Download today it's FREE! 
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> 
> 
> 
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Mirror for QEMU (sources)

2005-08-03 Thread Herbert Poetzl 
On Tue, Jul 26, 2005 at 05:26:15PM +0200, Pascal Terjan wrote:
> On 7/26/05, Lennert Buytenhek <[EMAIL PROTECTED]> wrote:
> > On Tue, Jul 26, 2005 at 02:16:49PM +0200, Hetz Ben Hamo wrote:
> > 
> > > http://qemu.dad-answers.com/download/
> > 
> > I've been making qemu snapshots (plus binary fc3/fc4 packages)
> > available for a while now at:
> > 
> > http://qemu.wantstofly.org/
> > 
> > This was done mostly for my own use, but others are free to leech.
> 
> I have a small repository with builds for Mandriva 10.0, 10.1 and 10.2
> on http://fasmz.org/~pterjan/rpm/
> I update them almost each time I update the cooker packages.

but unfortunately I could not find a src rpm for
those binary mandriva rpms of qemu :/

best,
Herbert

> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Mirror for QEMU (sources)

2005-08-03 Thread Herbert Poetzl 
On Wed, Aug 03, 2005 at 11:00:14AM +0200, Gwenole Beauchesne wrote:
> On Wed, 3 Aug 2005, Herbert Poetzl wrote:
> 
> > > I update them almost each time I update the cooker packages.
> > 
> > but unfortunately I could not find a src rpm for
> > those binary mandriva rpms of qemu :/
> 
> cooker/SRPMS/contrib on any mirror you may find. Except proxad.net at this 
> time, which is a little bit unsynced.
> 
> <ftp://ftp.belnet.be/linux/mandrake/devel/cooker/SRPMS/contrib/qemu-0.7.1-2mdk.src.rpm>
> is one.

great! thanks!

best,
Herbert

> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Connecting vde and LAN

2005-08-11 Thread Herbert Poetzl 
On Thu, Aug 11, 2005 at 06:00:12PM +0100, Paul Brook wrote:
> > I guess this means that VDE would have to provide a kernel-layer
> > component which grabs the packets from eth0 and provides the faked eth0
> > for the Host OS...
> 
> You can do all this with the standard linux tools. Something like the 
> following(untested) script. ifrename is part of the Linus Wireless Tools. If 
> your distro doesn't have it you can download it here:
> http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html

and nameif is a lot older, part of net-tools and
basically installed on every machine which has
ifconfig ... hmm, scratch the last part, it is
installed on every machine :)

HTH,
Herbert

> Paul
> 
> #! /bin/sh
> # Take eth0 down so it can be renamed
> ifdown eth0
> # Rename eth0, and create a new bridge interface called eth0
> # This avoids having to change host network configuration.
> ifrename -i eth0 -n realeth0
> brctl addbr eth0
> brctl addif eth0 realeth0
> # bring realeth0 up without an IP so the bridge can use it
> ifconfig realeth0 0.0.0.0 up
> # bring the new eth0 up
> ifup eth0
> # Start vde, and add it to the bridge.
> vde_switch -t tap0
> ifconfig tap0 0.0.0.0 up
> brctl addif eth0 tap0
> 
> 
> ___
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] x86_64 kernel with 32bit userspace

2006-04-01 Thread Herbert Poetzl 

Hey Folks!

this might sched some light on the x86_64 issues
reported over and over again ...
(maybe it's already fixed but I haven't tried yet)

[   78.890508] mount[39]: segfault at cffc rip f7f8d210 rsp 
8100d000 error 6
[  224.745093] sh[24]: segfault at fffeb9a0 rip 0809a27e rsp 
8100fffeb994 error 6
[  246.072068] sh[55]: segfault at fffeb1d0 rip 0809a27e rsp 
8100fffeb1c4 error 6
[  264.091665] echo[70]: segfault at cffc rip f7f66210 rsp 
8100d000 error 6

best,
Herbert



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] possible pic misbehaviour

2006-05-21 Thread Herbert Poetzl 

Hi Folks!

I started to play around with installing
NEXT/OPENSTEP last week and despite some
postings stating that it works 'somewhat'
I encountered several issues so far ...

the good news (for me) is that I could
resolve all of them and have it running
quite fine. now to the topic ...

one thing I had to modify was the pic
(i8259) behaviour, in a way which isn't
really obvious from the docs, even worse
the implementation seems to match the 
intel documentation perfectly

nevertheless as both operating systems
NEXTSTEP and OPENSTEP seem to require
my (or a similar/better) modification to 
handle interrupts correctly, and both 
do run quite fine on real hardware, I
suspect a non-obvious deviation in the
implementation.

here is the 'hack' I did to make it work

--- hw/i8259.c  2006-05-22 03:54:47.0 +0200
+++ hw/i8259.c  2006-05-22 03:54:47.0 +0200
@@ -119,7 +119,7 @@ static int pic_get_irq(PicState *s)
master, the IRQ coming from the slave is not taken into account
for the priority computation. */
 mask = s->isr;
-if (s->special_fully_nested_mode && s == &s->pics_state->pics[0])
+if (/* s->special_fully_nested_mode && */ s == &s->pics_state->pics[0])
 mask &= ~(1 << 2);
 cur_priority = get_priority(s, mask);
 if (priority < cur_priority) {


here is the initialization sequence 
observed (debug output) on the pics:

init[0,ICW1] = 11
init[1,ICW1] = 11
init[0,ICW2] = 08
init[1,ICW2] = 70
init[0,ICW3] = 04
init[1,ICW3] = 02
init[0,ICW4] = 01
init[1,ICW4] = 01
  
init[0,ICW1] = 11
init[0,ICW2] = 40
init[0,ICW3] = 04
init[0,ICW4] = 01
  
init[1,ICW1] = 11
init[1,ICW2] = 48
init[1,ICW3] = 02
init[1,ICW4] = 01

according to the specs, the full featured
mode is 'initially' turned on unless it
is specified otherwise (which is not the
case in the current implementation), but 
the observed init sequence IMHO turns it 
off again (ICW4=1), but without this or
some other AEOI functionality the first
irq on the slave pic will basically hang
the OS as the interrupt is not cleared on
the master ...

probably I just missed the obvious, but
I thought I'd better report that here ...

best,
Herbert

PS: will send a few more changes shortly












___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] sdl fix for mouse grab/hide

2006-05-25 Thread Herbert Poetzl 

Hi Folks!

IMHO the idea behind the grab/mouse hide was to
have relative mouse moves inside the window when
the mouse is grabbed ...

now the SDL documentation SDL_MouseMotionEvent(3)
says the following:

If the cursor is hidden (SDL_ShowCursor(0)) and the 
input is grabbed (SDL_WM_GrabInput(SDL_GRAB_ON)),
then the mouse will give relative motion events 
even when the cursor reaches the edge fo the screen.

which is almost met, except for qemu _not_ using
the SDL_ShowCursor() but instead doing a special
SDL_SetCursor(sdl_cursor_hidden), which results in
SDL _not_ transmitting the relative motion events
once the border is reached, which in turn gives
funny behaviour :)

the following patch fixes this:


diff -NurpP qemu-cvs20060522/sdl.c qemu-cvs20060522/sdl.c
--- qemu-cvs20060522/sdl.c  2006-05-23 01:18:33.0 +0200
+++ qemu-cvs20060522/sdl.c  2006-05-23 03:03:19.0 +0200
@@ -285,13 +285,13 @@ static void sdl_update_caption(void)
 
 static void sdl_hide_cursor(void)
 {
-SDL_SetCursor(sdl_cursor_hidden);
+SDL_ShowCursor(0);
 }
 
 static void sdl_show_cursor(void)
 {
 if (!kbd_mouse_is_absolute()) {
-   SDL_SetCursor(sdl_cursor_normal);
+   SDL_ShowCursor(1);
 }
 }
 

best,
Herbert



___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] ps2 mouse cleanups/fixes

2006-05-27 Thread Herbert Poetzl 

Hi Folks!

here is a cleanup/fix to the ps2 mouse emulation done 
by qemu: according to the ps2 protocol specification
the dx and dy values are 9 bit 2's complement where 
the most significant bit appears as a sign bit in the
first byte. similar for dz but 4 bit 2's complement 
here with or without sign extension (IM/Explorer)  

best,
Herbert


diff -NurpP qemu-cvs20060522/hw/ps2.c qemu-cvs20060522/hw/ps2.c
--- qemu-cvs20060522/hw/ps2.c   2006-04-12 23:09:07.0 +0200
+++ qemu-cvs20060522/hw/ps2.c   2006-05-23 03:30:37.0 +0200
@@ -246,44 +247,36 @@ void ps2_keyboard_set_translation(void *
 s->translate = mode;
 }
 
+#define min(a,b) ((ab)?a:b)
+
 static void ps2_mouse_send_packet(PS2MouseState *s)
 {
 unsigned int b;
 int dx1, dy1, dz1;
 
-dx1 = s->mouse_dx;
-dy1 = s->mouse_dy;
-dz1 = s->mouse_dz;
-/* XXX: increase range to 8 bits ? */
-if (dx1 > 127)
-dx1 = 127;
-else if (dx1 < -127)
-dx1 = -127;
-if (dy1 > 127)
-dy1 = 127;
-else if (dy1 < -127)
-dy1 = -127;
-b = 0x08 | ((dx1 < 0) << 4) | ((dy1 < 0) << 5) | (s->mouse_buttons & 0x07);
+dx1 = min(max(s->mouse_dx,-256),255);
+dy1 = min(max(s->mouse_dy,-256),255);
+
+b = (s->mouse_buttons & 0x07) | 0x08 | 
+   ((dx1 & 0x100) >> 4) | ((dy1 & 0x100) >> 3);
+
 ps2_queue(&s->common, b);
 ps2_queue(&s->common, dx1 & 0xff);
 ps2_queue(&s->common, dy1 & 0xff);
-/* extra byte for IMPS/2 or IMEX */
+
 switch(s->mouse_type) {
 default:
+   dz1 = s->mouse_dz;
 break;
-case 3:
-if (dz1 > 127)
-dz1 = 127;
-else if (dz1 < -127)
-dz1 = -127;
+case 3: /* Intellimouse */
+dz1 = min(max(s->mouse_dz,-8),7);
 ps2_queue(&s->common, dz1 & 0xff);
 break;
-case 4:
-if (dz1 > 7)
-dz1 = 7;
-else if (dz1 < -7)
-dz1 = -7;
-b = (dz1 & 0x0f) | ((s->mouse_buttons & 0x18) << 1);
+case 4: /* Intellimouse Explorer */
+dz1 = min(max(s->mouse_dz,-8),7);
+b = (dz1 & 0x08f) | 
+   ((s->mouse_buttons & 0x18) << 1);
 ps2_queue(&s->common, b);
 break;
 }




___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Qemu-devel] [Bug 932490] Re: Qemu fails on -fda /dev/fd0 when no medium is present

2017-09-13 Thread Herbert Poetzl 
Sorry, it has been more than five years and I don't have a system with a
floppy disk to test anymore.

Best,
Herbert

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/932490

Title:
  Qemu fails on -fda /dev/fd0 when no medium is present

Status in QEMU:
  Incomplete

Bug description:
  # qemu-system-x86_64 --version
  QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice 
Bellard

  # qemu-system-x86_64 -fda /dev/fd0
  qemu-system-x86_64: -fda /dev/fd0: could not open disk image /dev/fd0: No 
such device or address

  Starting with a medium (floppy disk) inserted, then removing or
  changing the medium works fine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/932490/+subscriptions