Vine Server 4.0a cannot display a MacBook Air 11 inch screen remotely - the resulting display is scrambled. The resolution in question is: 1366 by 768.
This has been an issue since it was released in October 2011. Any chance it will be fixed along with an update for Mountain Lioin?
We aren’t aware of any bugs in Vine Server that would cause this issue and we’ve not had any other reports of the screen being scrambled. You might try the latest beta available on the downloads page and let us know if that works any better for you.
I can report that this is still an issue with an MBA 11" running 10.8.2 and Vine Server 4.01. Reverse connection made to my TightVNC viewer in listen mode was scrambled completely.
Basically right now there is a bug in Vine Server on any Retina display Mac OS X machines. The system reports a different screen dimension than the actual number of pixels and that causes this scrambling.
Any idea when this will be fixed? Thanks!!!
These are two separate issues.
Issue 1) MBA Display scrambled (been an issue for almost 3 years already) - this is a separate and distinct issue from retina display issue - screen is COMPLETELY scrambled, unreadable
Issue 2) Retina Display - not scrambled, but more like “looking at the screen through a stereoscope”
I’ve given up on a fix, especially when the developer just refuses to acknowledge the problem “we’ve received no other reports”
Would be nice to see it fixed though…
[quote=“macsysadmin”]
Issue 1) MBA Display scrambled (been an issue for almost 3 years already) - this is a separate and distinct issue from retina display issue - screen is COMPLETELY scrambled, unreadable
Issue 2) Retina Display - not scrambled, but more like “looking at the screen through a stereoscope”
I’ve given up on a fix, especially when the developer just refuses to acknowledge the problem “we’ve received no other reports”
Would be nice to see it fixed though…[/quote]
I can confirm Issue 1. So consider this another report.
My guess is that it has something to do with the screen resolution. MBA 11" has a 1366x768 display. 1366 is not a multiple of 8. Most other resolutions are. Could that be a clue?
Changing the resolution on the Mac is a workaround that resolves this issue. To do this on Mountain Lion, got to System Preferences/Displays and change to Scaled.
This could be a VNC-client issue, but we have tried several clients and they all have the same problem. It’s not only a resolution issue. I’ve tried connecting to my Lenovo laptop (running X11 with Vino Server) with 1366x768 and that works.
Regardless of where the issue is, I think it would be worth the effort to fix this in Vine Server. Even if it means working around a client side bug. All clients I’ve tested have this issue, so fixing it in Vine Server will improve interoperability with all these clients.
I can confirm the problem with the MBA 11" display being scrambled when the native resolution (1366x768) is used. This occurs with the built in Screen Sharing client, the RealVNC client, and the TightVNC client on windows. The MBA11 is running 10.8.3, with VineServer 4.01.
All of these clients work fine when connected to the OS built in VNC server, so I would be inclined to believe the problem is within the Vine code somewhere.
I need to use a 3rd party server because the native server doesn’t seem to have an interface to tell it to connect to a remote listening client.
I’m attaching a screen capture showing this scrambled effect.
If any further debugging information is needed, feel free to contact me.
jim
Hi! I tested this with the latest java, VINE, under Mavericks today and see the same type of result as baadpuppy posted above. I tried multiple viewers with the same result. Setting scaling off (effectively shuts down RD) fixed the issue, but that’s hardly a viable workaround in 2013.
I’ll research this more and post later.
Warmest regards,
Michael
Ug… not java. Objective C libraries. Build with Xcode. Sorry for the confusion. I’m testing multiple solutions.
I am starting to make some progress here I think. I have found the code that sets up the structures for grabbing (& transporting) screen captures. Because the scaled mode works and the unscaled mode does not I am looking for differences in the behaviors of the code.
What I have mostly found though is that the base code is really old and of course is written in C and not objective C, meaning it uses Carbon Framework instead of Quartz. Carbon is the old C interface whereas Quartz is the objective-c interface. The Quartz methods have pixel resolution built into the classes, but the support for Carbon doesn’t seem as well-integrated. Quartz is the present now - not the future.
So, here are some critical changes for pixel resolution:
HIWindowGetBackingScaleFactor replaces the HIGetScaleFactor function; see “Getting Scale Factors.”
kHIWindowBitHighResolutionCapable represents the bit that sets the high-resolution-capable attribute.
kWindowHighResolutionCapableAttribute designates a window as being capable of supporting high-resolution content.
None of these changes are in the code. For what it’s worth, I’m looking at the svn code from the most recent release and the file I am focusing on is localbuffer.c. It is this file that seems to have code to set up the buffers for screen capture.
Anyway, I haven’t fixed the bug, but I’m posting progress to see if there is any feedback. Maybe this information gives you an idea? Maybe I’m looking at completely wrong code? I don’t think so though.
Thanks! I will update soon.
All the best,
Michael
After building I noticed a huge number of memory overwrite errors. I rebuilt with some memory debugging code and found the culprit: the rfbClientRec structure is different for c-modules that include rfb.h. The problem is the definition of CGPoint, which is correct in the core graphics headers but for some reason, only the CGPoint definition is declared in rfb.h. Some of the other programs have definitions of rfbClientRec structures and include CGGeometry.h which properly defines the structure for 64 bit and 32 bit architectures.
Was:
#ifndef COREGRAPHICS_H_
struct CGPoint {
float x;
float y;
};
typedef struct CGPoint CGPoint;
#endif
For 64 bit Macs should be:
#ifndef COREGRAPHICS_H_
struct CGPoint {
double x;
double y;
};
typedef struct CGPoint CGPoint;
#endif
This sounds like a simple problem but the references to data in the structure were 16 bytes off. This mostly affects the output buffer and other elements and before offloading the memory to a suballoc approach, it was impossible to see what was going on except that the client was receiving pure garbage and the host crashes randomly.
I am moving forward again, but this is very slow.
I too am running into this issue as part of a larger project. gom, is your code in a public repository anywhere? I’d like to look into the Retina display issue as well, but it sounds like you’ve done a fair amount of cleanup and bug fixing for compiling on 10.9 anyway, and I’d rather not repeat your efforts if you’re willing to share.
Thanks!
–E.O.
Right now my code is a bit of a mess and it wouldn’t really help you. I used the Vine code together with my own messaging system to set up connections, so I need to separate that code from the rest before I upload it to a public place.
Also, the retina display really doesn’t work much better and I have a ton of more serious issues. I will get back to it once I get back from vacation, but that will probably be August.
Sorry I can’t really help at this time.
I had the same display issue and I started reading the code to fix the issue.
We were using the following lines of code in main.c to get the number of bytes used to for a single row
if (floor(NSAppKitVersionNumber) > floor(NSAppKitVersionNumber10_6)) {
[i] [b]rfbScreen.paddedWidthInBytes = rfbScreen.width*rfbScreen.bitsPerPixel/8;[/b][/i]
}
else {
rfbScreen.paddedWidthInBytes = CGDisplayBytesPerRow(displayID);
}
E.g. If the screen width is not divisible by 16, I am getting the above mentioned issue. So I went and changed
if (floor(NSAppKitVersionNumber) > floor(NSAppKitVersionNumber10_6)) {
[i] [b]CGImageRef imageRef = CGDisplayCreateImage(displayID);
rfbScreen.paddedWidthInBytes = CGImageGetBytesPerRow(imageRef);
if (imageRef != NULL)
CGImageRelease(imageRef);[/b][/i]
}
else {
rfbScreen.paddedWidthInBytes = CGDisplayBytesPerRow(displayID);
}
This looks working to me, but I have not tested in different resolutions.
Please let me know if anyone has any comments.
Great! Do you have build with this change?
For some reason the formatting of this bulletin board is all messed up (?) so you can’t read all of previous answers…
Anyway the thing that was mentioned as a fix was
Setting scaling off (effectively shuts down RD) fixed the issue, but that’s hardly a viable workaround in 2013.
I too am experiencing this (I think its any display that is using DPI scaling, which is all recent ones).
Which means that all recent mac’s cannot use (easily) vine server.
Here is my example:
http://imgur.com/hKhfYgL
@dreamuth
would it be possible to post your updated code to github (i.e. “fork the project”) esp. along with working binaries? That would be awesome!
Cheers!
Yes. Works for me too.
Plus the code is less buggy. Still looks like memory is leaking though.
are there any pre built binaries anyone could point me to or make available by chance?
Also it appears that github accepts “pull requests” if the author of the patches here wants to get them integrated that would be great (it does apparently already support retina displays, FWIW).