[EMAIL PROTECTED] wrote:
lo
Yes I am absolutly sure we need this changes. The usb protocoll is a
very sophisticated work. There is an exactly defined sequence in which
packets are send. (I have made some small documentation about this:
http://217.20.126.200/tino/usb-order-of-events.pdf
http:/
"Alexander Voropay" <[EMAIL PROTECTED]> wrote:
Another issue:
IN:
0xbfc00424: mtc0 zero,$13
0x0001: raise_exception 0x11
The problem is a code *before* this :
==
mfc0v0,C0_SR
and v0,SR_SR# preserve Soft Reset
or v0,SR_BEV
Alexander Voropay wrote:
[snip]
> Unfortunately, this code clears CU0 bits in the CP0(SR).
> It makes CP0 unusable for program and causes an exception 11 :
> Coprocessor Unusable on the next CP0 access.
>
> The Qemu has a bug there. The "See MIPS Run" p.51 states:
>
> CU0 - Coprocessor 0 usable;
There's another point here.
When switching from the qemu monitor to the virtual machine window,
we enter ctrl-alt-1 and it seems these keys are passed too.
--- Anthony Liguori <[EMAIL PROTECTED]> a écrit :
> This is probably because numlock is not sent to the guest unless you are
> in grab mode.
"Thiemo Seufer" <[EMAIL PROTECTED]> wrote:
The Qemu has a bug there. The "See MIPS Run" p.51 states:
A patch which doesn't negate the HFLAGS_UM check fixes this and was
posted here a while ago.
Thx, found.
http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00148.html
Is it possible to p
[EMAIL PROTECTED] wrote:
this patch breaks some things:
Sorry guys but I could not fix all of it, so I need your help, I didn't
want to destroy anybodys work, but the new api makes it necessary to
change some files:
1. usb-linux.c and usb-bsd.c will not work without adoption of the new api
Lonnie Mendez wrote:
2. I did not test usb-hid and usb-hub
There was a usb tablet device added recently. You may want to cvs
up to account for that.
Disregard that. Just saw it ;p
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http:/
On Sat, Apr 08, 2006 at 10:12:07PM +0400, Brad Campbell wrote:
> Samuel Hunt wrote:
> >It occurs to me that this program would make an excellent basis for a
> >VNC terminal server.
[...]
> If you use the vnc patch you kinda get a large part of this already. Major
> issue is still mouse synch, b
Lonnie Mendez wrote:
known problems:
1. under linux the uhci controller reports an error if no usb device is
connected
The port registers on the uhci controller shows no appropriate
response to an HCHALT command that is issued and so the hcd puts the
controller into global suspend.
T
On 4/21/06, Troy Benjegerdes <[EMAIL PROTECTED]> wrote:
> Have you tried the vnc patch with current CVS? I'm seeing some issues
> with -vnc-and-sdl, and with -vnc only, it looks like something is not
> getting initialized, and I only see the qemu console in the vnc window.
> It appears the guest is
lo. The attached patch applied on top of your patchset seems to work
as far as signaling resume goes.
--- a/qemu/hw/usb-uhci.c2006-04-21 11:15:40.0 -0500
+++ b/qemu/hw/usb-uhci.c2006-04-21 11:17:08.0 -0500
@@ -32,6 +32,8 @@
// #define DEBUG
// #define DEBUG_PAC
Hello,
Lonnie Mendez wrote:
> Lonnie Mendez wrote:
>
>>
>> The port registers on the uhci controller shows no appropriate
>> response to an HCHALT command that is issued and so the hcd puts the
>> controller into global suspend.
>
> The problem is more likely that the controller is being suspe
you are too fast for me :)
Lonnie Mendez wrote:
> lo. The attached patch applied on top of your patchset seems to
> work as far as signaling resume goes.
>
>
>
>
___
Qemu-de
[EMAIL PROTECTED] wrote:
you are too fast for me :)
Had to rediff it. Fabrice already put the necessary bits in
uhci_update_irq. Right in front of my eyes too.
There is some funkiness going on with removing the device in the
linux guest once attached. Not sure what it is yet.
--- a/q
Lonnie Mendez wrote:
There is some funkiness going on with removing the device in the
linux guest once attached. Not sure what it is yet.
This problem is addressed in the attached patch.
--- a/qemu/hw/usb-uhci.c2006-04-21 11:15:40.0 -0500
+++ b/qemu/hw/usb-uhci.c20
Hi,
while playing with different -march options of MIPS GCC, I
found that GCC generates some special R5400 three register
multiply assembly commands if used with -march=vr5400 (MULS,
MULHI, MACC etc.). These commands use 11 bit extended
opcodes where the lowest 6 bits are the same as for the
sta
lo. A few more things to note in the current problems category:
-emulated devices don't seem to be interacting:
frame 36: pid=SETUP addr=0x00 ep=0 len=8
data_out= 80 06 00 01 00 00 40 00
frame 37: pid=SETUP addr=0x00 ep=0 len=8
data_out= 80 06 00 01 00 00 40 00
frame 38: pid=SETUP add
This is hopefully the final iteration of the Solaris patch.
The main difference between this patch and previous patches
was the cleanup of dyngen-exec.h. Previous patches #ifdef'd
out a bunch of linux code and irc discussions showed that
this was not a preferable solution. I reworked the patch
Another patch. This one does a few things:
-fixes minor output bugs and some various OBO bugs
-adds some improvements to the emulated hub
-sets up the emulated devices to use the generic message handler (they
now work again)
-makes tablet device visible to usb_add
There are of course more
Troy Benjegerdes wrote:
On Thu, Feb 09, 2006 at 04:01:34PM -0600, Anthony Liguori wrote:
Jim C. Brown wrote:
-kernel-kqemu virtualizes ring 0 code.
So it basically makes qemu do what VMware does.
IIRC someone reported a 33% speedup with the new option.
That was me. That was a 33% speedup o
Troy Benjegerdes wrote:
On Mon, Apr 10, 2006 at 12:23:05PM +0400, 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
21 matches
Mail list logo
