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. H
Hi Thiemo,
the goal of my patch (and the original which I derived from) was to give
the VGA device the ability to display correctly on BGR X servers. Most
likely this is for target-i386 emulation, such as for running Windows
guests. That's my need for the patch anyway. In my case, I'm tryin
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):
>
> http://lists.nongnu.org/archive/html/qemu-devel
G'day all,
This takes Anthony Liguori's <[EMAIL PROTECTED]> patch from this morning and rolls into it my hid
descriptor fixes and the wheel sdl double step fix.
I spent some time cleaning this all up. The following integrates Brad's patches and the patch from
http://gnome.dnsalias.net/patc
Ok.. and for my next trick.. one that is not whitespace damaged..
Functionally same as 002..
Brad (need caffeine or sleep)
--
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Dou
Brad Campbell wrote:
Brad Campbell wrote:
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 t
To be clear, I just ran into the problem of the update of the carry flag but
I'm not at all a specialist of SPARC assembly.
From what I've understood, Paul is certainly right when suggesting to add a
fix for the SPARC64 case (for the addxcc and subxcc, not addx and subx) and I
send a new versio
Brad Campbell wrote:
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
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
tonight
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.
:
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 fi
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 y
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 www.sparg.org
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. I
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
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 & 0xf
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!
http://toolbar.msn.click-url.com/go/onm00200415a
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
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.
We
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
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 implement
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 config
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
> 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.
>
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 doe
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 u
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
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 inte
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 understa
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 w
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
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
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 for the source if you want it, pay
for it, if you don't. Don't. He makes the
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'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 a
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 speakin
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 possibl
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
while
Leonardo E. Reiter wrote:
Anthony,
your patch works perfectly, even with Windows XP as well.
Make sure to give credit where credit's due. Brad Campbell figured out
the hard stuff :-)
The transition from the boot-time PS/2 mouse is perfect, and the way
the cursor grab logic is handled is
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, CM
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
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.
Anthony,
your patch works perfectly, even with Windows XP as well. The
transition from the boot-time PS/2 mouse is perfect, and the way the
cursor grab logic is handled is seamless. I haven't been able to test
the scroll wheel because I have some hardware restrictions today (laptop
only for
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 14:54:44
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
instan
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 to
Johannes Schindelin wrote:
With Xorg from CVS, the evdev driver segfaults. This is apparently expected
behavior. Hopefully it will be fixed soon. It works quite nicely under
Win2k.
Here is the vnc patch to go on top of that and the latest cvs.
Before anybody complains: vnc.c needs a major c
Hi,
On Mon, 10 Apr 2006, Brad Campbell wrote:
> Anthony Liguori wrote:
> > I spent some time cleaning this all up. The following integrates Brad's
> > patches and the patch from
> > http://gnome.dnsalias.net/patches/qemu-hidmousexp.patch
> >
> > It adds a new emulated USB device that reports ab
Anthony Liguori wrote:
I spent some time cleaning this all up. The following integrates Brad's
patches and the patch from
http://gnome.dnsalias.net/patches/qemu-hidmousexp.patch
It adds a new emulated USB device that reports absolute coordinates. It
also modifies SDL to operate in grabless
49 matches
Mail list logo
