[Qemu-devel] [Bug 925405] Re: VNC server does not work with Mac Screen Sharing
Well, I understand that since they do their own encoding (hence the need for a different protocol number for their stuff to talk to each other), but I don't think that's the whole thing, since I don't get any updates from the server, and the VNC spec (IIRC) allowed for negotiating a common version and encodings. Regardless, would it be feasible to fix this from a user perspective? (and Happy New Year!) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/925405 Title: VNC server does not work with Mac Screen Sharing Status in QEMU: Incomplete Status in Ubuntu: Invalid Bug description: When connecting to a QEMU instance from a Mac using any VNC settings on the QEMU CLI and any target arch (ARM, Intel, etc.), the connection is attempted but the negotiation never finishes. I've verified this when building QEMU from source (1.0 and HEAD) on Ubuntu, Fedora and Debian or when using Ubuntu (Oneiric) and Debian (Lenny) packages. It does not matter whether I specify authentication (or anything else) on QEMU's side, the behavior is always the same - I see the connection being established using netstat and tcpdump, but QEMU does not seem to send back any pixmap data after the connection setup. Best guess as to why this happens is that the VNC negotiation on QEMU does not like the protocol version and VNC encoding sent by the Mac's built-in VNC client, or that its negotiation logic is subtly broken. I appreciate that it's not meant to be a full VNC server, but it prevents me from using it remotely until a stable Mac build is feasible. Background info: Mac OS X includes a VNC client called Screen Sharing that you can invoke in two different ways: * At a terminal, by typing "open vnc://hostname:tcp_port" * From any URI-enabled field (such as the Safari URI field), where you can just type the URI as vnc://hostname:tcp_port Please do not confuse the enhanced VNC protocol Apple Remote Desktop uses with Screen Sharing - they are not mutually exclusive, but they are not incompatible either, since what Apple does is to negotiate extra pixmap encoding and authentication options - I use Screen Sharing to access many VNC servers such as vnc4server, tightvncserver, vino, etc. without any issues whatsoever, so the issue I'm reporting is not an issue with Apple's implementation. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/925405/+subscriptions
[Qemu-devel] [Bug 925405] Re: VNC server does not work with Mac Screen Sharing
Hey there. Will git tip from September do? At that time I built QEMU on Ubuntu 16.04.1, pointed my Mac (10.10) at it again and had the same experience (had to use a third-party client) Considering I opened this four years ago, I'm kind of surprised it's still a talking topic. Was kind of expecting more people to report it, but then again Launchpad is a bit off the beaten path these days and most people just sigh and fetch a third party client. It's just that it seems like a trivial thing to fix overall, so I thought it worthwhile to chime in - Happy New Year! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/925405 Title: VNC server does not work with Mac Screen Sharing Status in QEMU: Incomplete Status in Ubuntu: Invalid Bug description: When connecting to a QEMU instance from a Mac using any VNC settings on the QEMU CLI and any target arch (ARM, Intel, etc.), the connection is attempted but the negotiation never finishes. I've verified this when building QEMU from source (1.0 and HEAD) on Ubuntu, Fedora and Debian or when using Ubuntu (Oneiric) and Debian (Lenny) packages. It does not matter whether I specify authentication (or anything else) on QEMU's side, the behavior is always the same - I see the connection being established using netstat and tcpdump, but QEMU does not seem to send back any pixmap data after the connection setup. Best guess as to why this happens is that the VNC negotiation on QEMU does not like the protocol version and VNC encoding sent by the Mac's built-in VNC client, or that its negotiation logic is subtly broken. I appreciate that it's not meant to be a full VNC server, but it prevents me from using it remotely until a stable Mac build is feasible. Background info: Mac OS X includes a VNC client called Screen Sharing that you can invoke in two different ways: * At a terminal, by typing "open vnc://hostname:tcp_port" * From any URI-enabled field (such as the Safari URI field), where you can just type the URI as vnc://hostname:tcp_port Please do not confuse the enhanced VNC protocol Apple Remote Desktop uses with Screen Sharing - they are not mutually exclusive, but they are not incompatible either, since what Apple does is to negotiate extra pixmap encoding and authentication options - I use Screen Sharing to access many VNC servers such as vnc4server, tightvncserver, vino, etc. without any issues whatsoever, so the issue I'm reporting is not an issue with Apple's implementation. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/925405/+subscriptions
[Qemu-devel] [Bug 925412] Re: Cannot build on Mac using Xcode 4 and LLVM
Awesome, thanks. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/925412 Title: Cannot build on Mac using Xcode 4 and LLVM Status in QEMU: Fix Released Bug description: As detailed in the mailing-list and the brew project (see below), QEMU currently either doesn't build with LLVM or builds and crashes upon runtime on Mac OS X Lion (or Snow Leopard if you've upgraded your compiler from gcc-4.2). This seems to be tied to the internal representation of UINT16, but effectively means that you currently cannot run QEMU 1.0 or HEAD (for any target arch - I'm focusing on ARM and Intel) on a Mac. References: [1]: http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg01330.html [2]: https://github.com/mxcl/homebrew/pull/9520 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/925412/+subscriptions
[Qemu-devel] [Bug 925412] Re: Cannot build on Mac using Xcode 4 and LLVM
** Also affects: ubuntu Importance: Undecided Status: New ** No longer affects: ubuntu -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/925412 Title: Cannot build on Mac using Xcode 4 and LLVM Status in QEMU: New Bug description: As detailed in the mailing-list and the brew project (see below), QEMU currently either doesn't build with LLVM or builds and crashes upon runtime on Mac OS X Lion (or Snow Leopard if you've upgraded your compiler from gcc-4.2). This seems to be tied to the internal representation of UINT16, but effectively means that you currently cannot run QEMU 1.0 or HEAD (for any target arch - I'm focusing on ARM and Intel) on a Mac. References: [1]: http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg01330.html [2]: https://github.com/mxcl/homebrew/pull/9520 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/925412/+subscriptions
[Qemu-devel] [Bug 925405] Re: VNC server does not work with Mac Screen Sharing
** Also affects: ubuntu 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/925405 Title: VNC server does not work with Mac Screen Sharing Status in QEMU: New Status in Ubuntu: New Bug description: When connecting to a QEMU instance from a Mac using any VNC settings on the QEMU CLI and any target arch (ARM, Intel, etc.), the connection is attempted but the negotiation never finishes. I've verified this when building QEMU from source (1.0 and HEAD) on Ubuntu, Fedora and Debian or when using Ubuntu (Oneiric) and Debian (Lenny) packages. It does not matter whether I specify authentication (or anything else) on QEMU's side, the behavior is always the same - I see the connection being established using netstat and tcpdump, but QEMU does not seem to send back any pixmap data after the connection setup. Best guess as to why this happens is that the VNC negotiation on QEMU does not like the protocol version and VNC encoding sent by the Mac's built-in VNC client, or that its negotiation logic is subtly broken. I appreciate that it's not meant to be a full VNC server, but it prevents me from using it remotely until a stable Mac build is feasible. Background info: Mac OS X includes a VNC client called Screen Sharing that you can invoke in two different ways: * At a terminal, by typing "open vnc://hostname:tcp_port" * From any URI-enabled field (such as the Safari URI field), where you can just type the URI as vnc://hostname:tcp_port Please do not confuse the enhanced VNC protocol Apple Remote Desktop uses with Screen Sharing - they are not mutually exclusive, but they are not incompatible either, since what Apple does is to negotiate extra pixmap encoding and authentication options - I use Screen Sharing to access many VNC servers such as vnc4server, tightvncserver, vino, etc. without any issues whatsoever, so the issue I'm reporting is not an issue with Apple's implementation. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/925405/+subscriptions
[Qemu-devel] [Bug 925412] [NEW] Cannot build on Mac using Xcode 4 and LLVM
Public bug reported: As detailed in the mailing-list and the brew project (see below), QEMU currently either doesn't build with LLVM or builds and crashes upon runtime on Mac OS X Lion (or Snow Leopard if you've upgraded your compiler from gcc-4.2). This seems to be tied to the internal representation of UINT16, but effectively means that you currently cannot run QEMU 1.0 or HEAD (for any target arch - I'm focusing on ARM and Intel) on a Mac. References: [1]: http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg01330.html [2]: https://github.com/mxcl/homebrew/pull/9520 ** 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/925412 Title: Cannot build on Mac using Xcode 4 and LLVM Status in QEMU: New Bug description: As detailed in the mailing-list and the brew project (see below), QEMU currently either doesn't build with LLVM or builds and crashes upon runtime on Mac OS X Lion (or Snow Leopard if you've upgraded your compiler from gcc-4.2). This seems to be tied to the internal representation of UINT16, but effectively means that you currently cannot run QEMU 1.0 or HEAD (for any target arch - I'm focusing on ARM and Intel) on a Mac. References: [1]: http://lists.gnu.org/archive/html/qemu-devel/2012-01/msg01330.html [2]: https://github.com/mxcl/homebrew/pull/9520 To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/925412/+subscriptions
[Qemu-devel] [Bug 925405] [NEW] VNC server does not work with Mac Screen Sharing
Public bug reported: When connecting to a QEMU instance from a Mac using any VNC settings on the QEMU CLI and any target arch (ARM, Intel, etc.), the connection is attempted but the negotiation never finishes. I've verified this when building QEMU from source (1.0 and HEAD) on Ubuntu, Fedora and Debian or when using Ubuntu (Oneiric) and Debian (Lenny) packages. It does not matter whether I specify authentication (or anything else) on QEMU's side, the behavior is always the same - I see the connection being established using netstat and tcpdump, but QEMU does not seem to send back any pixmap data after the connection setup. Best guess as to why this happens is that the VNC negotiation on QEMU does not like the protocol version and VNC encoding sent by the Mac's built-in VNC client, or that its negotiation logic is subtly broken. I appreciate that it's not meant to be a full VNC server, but it prevents me from using it remotely until a stable Mac build is feasible. Background info: Mac OS X includes a VNC client called Screen Sharing that you can invoke in two different ways: * At a terminal, by typing "open vnc://hostname:tcp_port" * From any URI-enabled field (such as the Safari URI field), where you can just type the URI as vnc://hostname:tcp_port Please do not confuse the enhanced VNC protocol Apple Remote Desktop uses with Screen Sharing - they are not mutually exclusive, but they are not incompatible either, since what Apple does is to negotiate extra pixmap encoding and authentication options - I use Screen Sharing to access many VNC servers such as vnc4server, tightvncserver, vino, etc. without any issues whatsoever, so the issue I'm reporting is not an issue with Apple's implementation. ** 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/925405 Title: VNC server does not work with Mac Screen Sharing Status in QEMU: New Bug description: When connecting to a QEMU instance from a Mac using any VNC settings on the QEMU CLI and any target arch (ARM, Intel, etc.), the connection is attempted but the negotiation never finishes. I've verified this when building QEMU from source (1.0 and HEAD) on Ubuntu, Fedora and Debian or when using Ubuntu (Oneiric) and Debian (Lenny) packages. It does not matter whether I specify authentication (or anything else) on QEMU's side, the behavior is always the same - I see the connection being established using netstat and tcpdump, but QEMU does not seem to send back any pixmap data after the connection setup. Best guess as to why this happens is that the VNC negotiation on QEMU does not like the protocol version and VNC encoding sent by the Mac's built-in VNC client, or that its negotiation logic is subtly broken. I appreciate that it's not meant to be a full VNC server, but it prevents me from using it remotely until a stable Mac build is feasible. Background info: Mac OS X includes a VNC client called Screen Sharing that you can invoke in two different ways: * At a terminal, by typing "open vnc://hostname:tcp_port" * From any URI-enabled field (such as the Safari URI field), where you can just type the URI as vnc://hostname:tcp_port Please do not confuse the enhanced VNC protocol Apple Remote Desktop uses with Screen Sharing - they are not mutually exclusive, but they are not incompatible either, since what Apple does is to negotiate extra pixmap encoding and authentication options - I use Screen Sharing to access many VNC servers such as vnc4server, tightvncserver, vino, etc. without any issues whatsoever, so the issue I'm reporting is not an issue with Apple's implementation. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/925405/+subscriptions
Re: [Qemu-devel] LLVM builds on Lion (Xcode 4.2.1)?
On Jan 11, 2012, at 19:24 , Peter Maydell wrote: > This is still waiting for somebody to get round to doing a basic > noddy FPU-intensive benchmark of (eg) an ARM target on a Linux > host to find out whether int16_t vs int_fast16_t makes any > difference at all to performance. (My suspicion is 'no'.) Quite so - I've since exchanged a couple of messages with Andreas and ascertained that. But QEMU not running properly when compiled with LLVM is the real problem here, since that means people won't be able to build it unless they have an outdated compiler around (fresh installs of Xcode don't bundle "normal" gcc anymore). I'm starting to think I'm the only person trying to build it with a current Mac toolchain... R.
[Qemu-devel] LLVM builds on Lion (Xcode 4.2.1)?
Hello, I posted this to the list a couple of days ago but I still don't see it in the archives, so here goes again... I've been trying to get a working build of QEMU 1.0 (or HEAD) that would build or run on Mac OS X Lion without segfaulting or spinlocking, and so far the only way I've been able to build it _and_ run it is by using gcc-4.2 instead of LLVM. Clang doesn't work either (it doesn't support global register variables). I was wondering who might be looking into that, since I couldn't figure out where this kind of issue would be classified in the MAINTAINERS file I've only found Andreas (hi!) listed where it concerns Cocoa, but this is not a Cocoa issue. For the record, the way I got it to build was patching fpu/softfloat.h (see below, I think this has been submitted as a formal patch by someone else, but can't find it either) and setting --cc=gcc-4.2 --host-cc=gcc-4.2. The issue with that is that "plain" GCC isn't bundled with Xcode anymore (even though I have it on all the machines I tried this, it was apparently removed around Xcode 4.1 or thereabouts and my upgrades preserved it), so I'd like to get in touch with someone that might be able to address the LLVM issue. Regards, R. http://the.taoofmac.com -- diff --git a/fpu/softfloat.h b/fpu/softfloat.h index 07c2929..229d834 100644 --- a/fpu/softfloat.h +++ b/fpu/softfloat.h @@ -57,7 +57,7 @@ typedef uint8_t flag; typedef uint8_t uint8; typedef int8_t int8; #ifndef _AIX -typedef int uint16; +typedef uint16_t uint16; -typedef int int16; +typedef int16_t int16; #endif typedef unsigned int uint32; (remember, this is not a formal patch)
[Qemu-devel] LLVM builds on Lion (Xcode 4.2.1)?
Hello, I've been trying to get a working build of QEMU 1.0 (or HEAD) that would build or run on Mac OS X Lion without segfaulting or spinlocking, and so far the only way I've been able to build it _and_ run it is by using gcc-4.2 instead of LLVM. Clang doesn't work either (it doesn't support global register variables). I was wondering who might be looking into that, since I couldn't figure out where this kind of issue would be classified in the MAINTAINERS file I've only found Andreas (hi!) listed where it concerns Cocoa, but this is not a Cocoa issue. For the record, the way I got it to build was patching fpu/softfloat.h (see below, I think this has been submitted as a formal patch by someone else, but can't find it either) and setting --cc=gcc-4.2 --host-cc=gcc-4.2. The issue with that is that "plain" GCC isn't bundled with Xcode anymore (even though I have it on all the machines I tried this, it was apparently removed around Xcode 4.1 or thereabouts and my upgrades preserved it), so I'd like to get in touch with someone that might be able to address the LLVM issue. Regards, R. http://the.taoofmac.com -- diff --git a/fpu/softfloat.h b/fpu/softfloat.h index 07c2929..229d834 100644 --- a/fpu/softfloat.h +++ b/fpu/softfloat.h @@ -57,7 +57,7 @@ typedef uint8_t flag; typedef uint8_t uint8; typedef int8_t int8; #ifndef _AIX -typedef int uint16; +typedef uint16_t uint16; -typedef int int16; +typedef int16_t int16; #endif typedef unsigned int uint32; (remember, this is not a formal patch)
Re: [Qemu-devel] VNC patch status?
Thanks, I'll look into CVS. My primary use for it is being able to access Linux VM consoles - although I'm curious as to the mouse issues other folk are mentioning - is it a Win98 specific issue? (the only Windows I run inside QEMU is XP, and I use RDP to reach that...) Regards, Rui Carmo http://the.taoofmac.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] VNC patch status?
Hello, I was wondering about the status of the VNC patch that was available a few months back (i.e., whether it's still useful for 0.7.2) and whether or not it was being considered for inclusion in the main source tree. Regards, Rui Carmo http://the.taoofmac.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
