Hi,
On Mon, 10 Apr 2006, Brad Campbell wrote:
Not complaining at all. I was looking at removing the magic mouse stuff but
that would then remove functionality for clients that currently can't use the
hid-abs support. So I left it there and patched it up to work.
Good! I'll give it a try
On Thu, 2006-04-06 at 19:06 +0200, Pascal Terjan wrote:
Does -smp 2 option use both CPUs of my host, or only one?
only one
Is there any way to use two host CPUs in Qemu?
No
Sorry, I am late for this discussion.
On multi-core/multi-proc architecture, how are dispatched the qemu
instances of
Am Freitag, 7. April 2006 17:44 schrieb Blue Swirl:
Hi!
The attached patch is an updated version of my previous patch. Now it applies
cleanly to cvs head and the read and write performance is increased.
regards,
Jörg
--- esp.c 2006-04-10 14:51:37.0 +0200
+++ esp.c.new 2006-04-10
Hi,
I would like to know why is kqemu not GPL?
Would you know?
--
A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source GPL).
Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better.
http://www.cps-project.org for downloads documentation.
I'm sorry to bring this issues back from the dead:
* Full disk issues
* Service pack issues
I Do know that both these issues have been dealt before, but yet,
there is no fix from the QEMU application itself, compared to the
competitors..
One thing that I don't understand is: are these issues
Fabrice is the owner of the KQEMU code, and he decides for his own
reasons to put the code under closed source license.
Thanks,
Hetz
On 4/10/06, Rakotomandimby Mihamina
[EMAIL PROTECTED] wrote:
Hi,
I would like to know why is kqemu not GPL?
Would you know?
--
A powerfull GroupWare, CMS,
Hetz,
persumably asynchronous I/O in the IDE device will solve the disk full
issue. Basically that is what the win2k-hack emulates, in its simplest
form. Asynchronous I/O will do this for real, as well as probably
improve the feel of the VM. If you use the win2k-hack patch I posted a
Sorry about that... Brad, very well done!
On another note, I'm looking over the USB HID spec to better understand
the boot-time device constraints. I doubt you can use an absolute
coordinate tablet as a boot-time mouse that actually reports positions
in absolute terms, but maybe it's
On Mon, 10 Apr 2006 17:20:54 +0200, Hetz Ben Hamo [EMAIL PROTECTED] wrote:
Fabrice is the owner of the KQEMU code, and he decides for his own
reasons to put the code under closed source license.
I'm sure that Fabrice knows and that I'm beating a dead horse, but this is
(strictly speaking,
I'm sure that Fabrice knows and that I'm beating a dead horse, but this is
(strictly speaking, discussions pending ;^)) violating the linux kernel
license agreement.
Actually it doesn't, as kqemu is not part of any kernel. it's just
another closed source module as nvidia's module as well as
No it's not! In fact, in the latest version, he explicitly gives it a
commercial (Proprietary) license. He also does not import any
exported GPL symbols from the kernel. In fact, if your claim is true,
then the following very popular products violate the kernel license
agreement:
VMware
I second that, very emphatically!
- Leo Reiter
Brett (Mare) Henley wrote:
This is all very disturbing, Fabrice wrote an enhancement to qemu
that runs perfectly fine without KQEMU. Why should anyone have a problem
with what license he uses or terms he decides?
He wants a very reasonable price
I strongly support the idea of being able to use shared objects to be
able to have a more dynamic device model; I can work on moving some of
the drivers over to whatever new model that you figure out.
It'd be nice too to have a dynamic board definition. For instance,
being able to describe in
Leonardo E. Reiter wrote:
Sorry about that... Brad, very well done!
Ta :)
Anthony did a great job doing the stuff I'm knaff at (making clean and mergable code) and the sdl
hookups.
I just hacked the hid stuff (about 150 win2k reboots in there).
It works with Win98 also, but Win98 seems to
Hetz Ben Hamo wrote:
I'm sorry to bring this issues back from the dead:
* Full disk issues
* Service pack issues
I Do know that both these issues have been dealt before, but yet,
there is no fix from the QEMU application itself, compared to the
competitors..
One thing that I don't understand
Hello,
attached is an updated version (against today's CVS) of a patch to
enable B/G/R color encoding rather than R/G/B with the command-line
option -bgr. I found the original here (post by Martin Bochnig):
http://lists.nongnu.org/archive/html/qemu-devel/2005-09/msg00059.html
It's main
On Monday 10 April 2006 17:25, Leonardo E. Reiter wrote:
Hello,
attached is an updated version (against today's CVS) of a patch to
enable B/G/R color encoding rather than R/G/B with the command-line
option -bgr. I found the original here (post by Martin Bochnig):
Shouldn't we be able to
You can definitely figure it out by asking the X server or SDL. I don't
know enough SDL to have hacked it in myself. X is pretty simple on the
other hand.
As for where to add it, I agree that the low level conversions are not a
great place to add this. I didn't originate the patch, I just
Actually it should probably be made conditionally compiled for now,
until the VGA architecture changes to something more efficient. Would
you agree with that? That way, people who know they will need the hack
can enable it at configure/compile time, and the rest will not be affected.
How
Unfortunately X11 will not allow you to force a certain color order in
24-bit mode. You can tell it to force byte-order but this only affects
16-bit blits - it's ignored for 24-bit since the individual components
of the 24-bit blits, even if packed into 32-bits, are still 8-bits long.
Okay, that makes perfect sense. Let me see if I can figure out how to
get SDL to report the ordering, and I'll try to roll it out that way.
thanks for clarifying,
- Leo Reiter
Paul Brook wrote:
Unfortunately X11 will not allow you to force a certain color order in
24-bit mode. You can tell
On Monday 10 April 2006 17:44, Leonardo E. Reiter wrote:
Actually it should probably be made conditionally compiled for now,
until the VGA architecture changes to something more efficient. Would
you agree with that? That way, people who know they will need the hack
can enable it at
I was talking about enabling the use of the -bgr flag at compile time,
to save the check at runtime if the user doesn't even care about the
flag, not forcing the determination of the blit order altogether at
compile-time. In any case, this is moot, your clarification on how to
better
On Monday 10 April 2006 17:51, Leonardo E. Reiter wrote:
I was talking about enabling the use of the -bgr flag at compile time,
to save the check at runtime if the user doesn't even care about the
flag, not forcing the determination of the blit order altogether at
compile-time. In any case,
Juergen Pfennig wrote:
Hello ...
Please note: I will send the Async IO stuff later, see below.
This Patch: Here is a very simple patch to ide.c that does not change
the controller type and that lets an existing win2003 in-
stallation use multi-sector IO and/or DMA.
I send a patch that should fix a bug in the update of carry flag for addxcc
and subxcc instructions when the carry flag is set before the evaluation of
the instruction.
(the fix is identical to what is done in the similar instruction
op_adcl_T0_T1_cc for arm target)
Looks good, but what about V
Doesn't this condition in addx and the corresponding line in subx need
similar
treatment?
They don't change the flags.
_
FREE pop-up blocking with the new MSN Toolbar - get it now!
On Monday 10 April 2006 19:04, Blue Swirl wrote:
Doesn't this condition in addx and the corresponding line in subx need
similar
treatment?
They don't change the flags.
It certainly look like they do.
In particular if TARGET_SPARC64 we have
if ((T0 0x) (src1 0x))
Here's a better patch... I can't seem to validate BGR X servers in 15 or
16-bit mode. This may not make sense (or be prevalent) on little-endian
machines anyway (I'm using VNC server on a little endian box to test
against.) In any case, 24 and 32-bit works like a charm. I use the
same basic
Here's a better patch (attached this time!)...
I can't seem to validate BGR X servers in 15 or
16-bit mode. This may not make sense (or be prevalent) on little-endian
machines anyway (I'm using VNC server on a little endian box to test
against.) In any case, 24 and 32-bit works like a charm.
Blue Swirl a écrit :
Doesn't this condition in addx and the corresponding line in subx need
similar
treatment?
They don't change the flags.
ADDX (now named ADDC in v9) doesn't change the flags, while ADDXcc
(ADDCcc) does. The cc versions also compute overflow.
cf. SPARC v9 on
On Mon, 10 Apr 2006, Leonardo E. Reiter wrote:
Anyway, I didn't spend time figuring out how to query SDL for the ordering.
You still have to manually pass in -bgr. The good news is that all the
computation is now done at compile-time, with only very few tests done at
run-time. I agree with
Probably... I just don't know anything about SDL and I needed this patch
to work right away with at least the command-line option. It's
definitely deducible from X11, and that's very easy.
- Leo Reiter
malc wrote:
On Mon, 10 Apr 2006, Leonardo E. Reiter wrote:
Anyway, I didn't spend time
In message: [EMAIL PROTECTED]
Auke Kok [EMAIL PROTECTED] writes:
:
:
: On Mon, 10 Apr 2006 17:20:54 +0200, Hetz Ben Hamo [EMAIL PROTECTED] wrote:
: Fabrice is the owner of the KQEMU code, and he decides for his own
: reasons to put the code under closed source license.
:
: I'm
Brad Campbell wrote:
The wheel works in SDL although there is currently a bug where it steps
by 2 instead of 1.. so it's ok for scrolling, but scrolling through a
selection box causes it to skip every second selection.
I've not tested the wheel with the vnc patch yet. I'll get to those
Leonardo E. Reiter wrote:
No it's not! In fact, in the latest version, he explicitly gives it a
commercial (Proprietary) license.
I actually submitted this as a patch to him through this list ;^)
I admit since I am a vendor, I have certain biases against forcing all
software to be GPL.
36 matches
Mail list logo
