Thread: [cotvnc-devel] Hello from OSXvnc
Project superseded by http://chicken.sourceforge.net/
Brought to you by:
smeger
From: Jonathan G. <jon...@re...> - 2004-03-23 16:25:22
|
Hi there, My name is Jonathan Gillaspie and I'm the principal developer/maintainer for the OSXvnc project. I've gone ahead and joined this list to help facilitate communication between our two projects - I want to make sure users of OS X have one of the best VNC setups available. I got the digest last night so I'll go ahead and reply on some things for clarification. -- Jonathan Gillaspie jon...@re... Redstone Software, Inc. -- Makers of Platform-Independent Automation Software -- http://www.redstonesoftware.com On Mar 22, 2004, at 9:04 PM, cot...@li... wrote: > Send cotvnc-devel mailing list submissions to > cot...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/cotvnc-devel > or, via email, send a message with subject or body 'help' to > cot...@li... > > You can reach the person managing the list at > cot...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of cotvnc-devel digest..." > > > Today's Topics: > > 1. Re: Big Huge Oops (Jared McIntyre) > 2. Re: Big Huge Oops (Jared McIntyre) > 3. Re: Chicken of the VNC ZRLE Encoding > (=?ISO-8859-1?Q?S=E9bastien_Desvignes?=) > 4. [ cotvnc-Bugs-917708 ] Strange colors with 24 bits RGB - ZRLE > (SourceForge.net) > 5. Re: Chicken of the VNC ZRLE Encoding (Jared McIntyre) > > --__--__-- > > Message: 1 > Date: Sun, 21 Mar 2004 23:47:41 -0700 > To: Jason Harris <sm...@ge...>, > cot...@li... > From: Jared McIntyre <jmc...@df...> > Subject: Re: [cotvnc-devel] Big Huge Oops > > At 12:57 PM -0700 3/21/04, Jason Harris wrote: >> Mime-Version: 1.0 (Apple Message framework v613) >> Content-Type: multipart/signed; micalg=sha1; >> boundary=Apple-Mail-24-660119039; >> protocol="application/pkcs7-signature" >> >> I noticed this when I synced with the tree. Your changes are >> looking nice so far! >> >> I think if possible, though, you should try to back out of them on >> the main branch. I know that there are random people trying to >> compile builds from it, so I'd like to keep it in a known state as >> much as possible. I had to do a bit of tweaking to get a clean >> build from it. >> >> If it helps, I've got a snapshot from before your changes. It's got >> some changes to the ZRLE files, but everything else, I think, was >> fresh from CVS. >> >> Jason > > Its actually labeled where the changes start, so it'll be pretty easy > to move it back out. It'll just take time. I'm not going to be able > to make those shifts until later in the week however. I'll update > everyone when I do. > > Jared > > > --__--__-- > > Message: 2 > Date: Mon, 22 Mar 2004 02:32:12 -0700 > To: cot...@li... > From: Jared McIntyre <jmc...@df...> > Subject: Re: [cotvnc-devel] Big Huge Oops > > I couldn't sleep this evening, so I took the time to revert > everything back and migrate the new code to the correct label. All > the new code is in GEN_2_GUI and everything else is reverted back to > where it was before I touched it. After a cursory build and test, it > would appear that everything is back to working the way it was. I > did notice that the passwords weren't really sticking between > runnings of the program, but I'm pretty sure that was the way it was > before I started working with it (that was one of the earlier things > I changed). > > Jared > > > --__--__-- > > Message: 3 > Date: Mon, 22 Mar 2004 22:51:54 +0100 > From: =?ISO-8859-1?Q?S=E9bastien_Desvignes?= <bo...@op...> > To: Jason Harris <sm...@ge...> > Cc: cot...@li... > Subject: [cotvnc-devel] Re: Chicken of the VNC ZRLE Encoding > > Jason Harris a =E9crit : > >> Hi Bob, >> >> I was wondering if you can join the Chicken development mailing >> list=20 >> so we can discuss this bug in a way that the other devs can see the >> =20 >> discussion too. The signup page is at >> http://lists.sourceforge.net/lists/listinfo/cotvnc-devel >> > Done. > >> My current status regarding this bug is (as of this writing) on the >> =20 >> most recent response on the ZLIB encoding bug page at >> >> Can you check it out and let me know what other problems you'd seen? >> =20 >> Everything seems to be working fine on my end now. >> > Well, unfortunately, the problem isn't that simple. The problem is > that=20 > RealVnc doesn't behave like the other Vnc servers (OSXvnc and > TightVnc=20 > for example). So, my solution solves the problem with RealVnc, but > it=20 > breaks with the others. > When RealVnc is set to depth 32, it uses a packed pixel size of 3 > bytes. > When OSXVnc (or TightVnc) is set to depth 32, it uses a packed pixel=20 > size of 4 bytes. > The correct way to solve this problem would be to detect > specifically=20 > RealVnc to choose the correct size for packed pixels. I don't know > how=20 > to do that. > Another solution would be to ask depth 24 when the server reports > depth=20 > 32 and chicken is set to server native. There are other problems > with=20 > depth 24 (almost solved in CVS), but it should be more manageable. > > A+, > Bob. > --=20 > <http://www.ophiuchus.org/> > Seule la mort peut gu=E9rir la stupidit=E9. (proverbe japonais) > Poser une question stupide est moins stupide que de rester dans > l'ignorance de la r=E9ponse. (proverbe de Bob) > > > > --__--__-- > > Message: 4 > To: no...@so... > From: "SourceForge.net" <no...@so...> > Date: Mon, 22 Mar 2004 13:57:23 -0800 > Subject: [cotvnc-devel] [ cotvnc-Bugs-917708 ] Strange colors with 24 > bits RGB - ZRLE > > Bugs item #917708, was opened at 2004-03-16 16:03 > Message generated for change (Comment added) made by nobody > You can respond by visiting: > https://sourceforge.net/tracker/? > func=detail&atid=507159&aid=917708&group_id=64347 > > Category: None > Group: None > Status: Pending > Resolution: Fixed > Priority: 5 > Submitted By: Nobody/Anonymous (nobody) > Assigned to: Jason Harris (smeger) > Summary: Strange colors with 24 bits RGB - ZRLE > > Initial Comment: > When I use the 24 bits RGB Pixel format and the ZRLE > encoding, the colors are very strange. All colors seems > to be shifted toward the cian color. > Server : > OSXvnc > Server reports Version RFB 003.003 > Transport Pixelformat: > trueColor = YES > bigEndian = YES > bitsPerPixel = 32 > depth = 24 > maxValue(r/g/b) = (255/255/255) > shift(r/g/b) = (24/16/8) > > In that case, the pixel data are packed in the most > significant bits of the pixel, but the reader put them > in the least signicant bits (function cvt_pixel24) > > -- > bob (at) ophiuchus (dot) org > > ---------------------------------------------------------------------- > > Comment By: Nobody/Anonymous (nobody) > Date: 2004-03-22 13:57 > > Message: > Logged In: NO > > The function splitRGB has the same problem than the function > cvt_pixel24. > You fixed the function cvt_pixel24, but the function > splitRGB is still broken. > > ---------------------------------------------------------------------- > > Comment By: Jason Harris (smeger) > Date: 2004-03-20 18:48 > > Message: > Logged In: YES > user_id=351330 > > Fixed in CVS. However, Tight is broken when connecting to OSXVnc. Not > sure if this is a new one or the same bug. > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/? > func=detail&atid=507159&aid=917708&group_id=64347 > > > --__--__-- > > Message: 5 > Date: Mon, 22 Mar 2004 18:50:12 -0700 > To: =?iso-8859-1?Q?S=E9bastien?= Desvignes <bo...@op...>, > Jason Harris <sm...@ge...> > From: Jared McIntyre <jmc...@df...> > Subject: [cotvnc-devel] Re: Chicken of the VNC ZRLE Encoding > Cc: cot...@li... > >> Well, unfortunately, the problem isn't that simple. The problem is >> that RealVnc doesn't behave like the other Vnc servers (OSXvnc and >> TightVnc for example). So, my solution solves the problem with >> RealVnc, but it breaks with the others. >> When RealVnc is set to depth 32, it uses a packed pixel size of 3 >> bytes. >> When OSXVnc (or TightVnc) is set to depth 32, it uses a packed pixel >> size of 4 bytes. >> The correct way to solve this problem would be to detect >> specifically RealVnc to choose the correct size for packed pixels. I >> don't know how to do that. >> Another solution would be to ask depth 24 when the server reports >> depth 32 and chicken is set to server native. There are other >> problems with depth 24 (almost solved in CVS), but it should be more >> manageable. > > That's definitely interesting. If that is the case, I think it may > be an issue in Real, since I remember reading the spec a few days ago > specifying that 24 was the top end for 3 byte. I'd have to look > again, however, to validate. If that is the case, we should bring it > to the attention of the RealVNC team and get their thoughts (though > they have been less than helpful in the past). > > Jared > > > > --__--__-- > > _______________________________________________ > cotvnc-devel mailing list > cot...@li... > https://lists.sourceforge.net/lists/listinfo/cotvnc-devel > > > End of cotvnc-devel Digest |
From: Jonathan G. <jon...@re...> - 2004-03-23 16:37:54
|
On Mar 22, 2004, at 9:04 PM, cot...@li... wrote: > >> My current status regarding this bug is (as of this writing) on the >> =20 >> most recent response on the ZLIB encoding bug page at >> >> Can you check it out and let me know what other problems you'd seen? >> =20 >> Everything seems to be working fine on my end now. >> > Well, unfortunately, the problem isn't that simple. The problem is > that=20 > RealVnc doesn't behave like the other Vnc servers (OSXvnc and > TightVnc=20 > for example). So, my solution solves the problem with RealVnc, but > it=20 > breaks with the others. > When RealVnc is set to depth 32, it uses a packed pixel size of 3 > bytes. > When OSXVnc (or TightVnc) is set to depth 32, it uses a packed pixel=20 > size of 4 bytes. > The correct way to solve this problem would be to detect > specifically=20 > RealVnc to choose the correct size for packed pixels. I don't know > how=20 > to do that. > Another solution would be to ask depth 24 when the server reports > depth=20 > 32 and chicken is set to server native. There are other problems > with=20 > depth 24 (almost solved in CVS), but it should be more manageable. I did some testing on this last week. When the OSXvnc Server bits per pixel is 32 it will practically always send a packed 3-byte color as long as the max for each color fits in 8 bits (which I've never seen it not do). There was a slight inconsistency in OSXvnc 1.32 (and earlier) where it would report the server native depth to always be the same as BPP, some clients (like CotVNC's tip of sourcecode-nobranch) might be confused by this and expect to NOT get a 3-byte CPixel even though that is still what it sent. So I went ahead and set depth=24 and BPP=32 when running millions of colors for OSXvnc 1.33. When I tested with a COTVNC checkout (no branches) it worked fine for server native and worked but had the color shift when the client specified the 24-bit depth. Not sure if this is a CotVNC problem or OSXvnc. -- Jonathan Gillaspie jon...@re... Redstone Software, Inc. -- Makers of Platform-Independent Automation Software -- http://www.redstonesoftware.com |
From: Jared M. <jmc...@df...> - 2004-03-24 05:11:02
|
>I did some testing on this last week. When the OSXvnc Server bits >per pixel is 32 it will practically always send a packed 3-byte >color as long as the max for each color fits in 8 bits (which I've >never seen it not do). > >There was a slight inconsistency in OSXvnc 1.32 (and earlier) where >it would report the server native depth to always be the same as >BPP, some clients (like CotVNC's tip of sourcecode-nobranch) might >be confused by this and expect to NOT get a 3-byte CPixel even >though that is still what it sent. So I went ahead and set depth=24 >and BPP=32 when running millions of colors for OSXvnc 1.33. > >When I tested with a COTVNC checkout (no branches) it worked fine >for server native and worked but had the color shift when the client >specified the 24-bit depth. Not sure if this is a CotVNC problem or >OSXvnc. In doing some further testing on this theme after we talked last week, I was able to track my crash down to having the Tight setting. So, the changes to Chicken allowed it to work against all server platforms with everything but tight encoding turned on. With tight encoding on, Chicken ran into serious issues talking to OSXVnc, but was fine running against RealVNC. I don't know if there is, perhaps, an endian issue in Chicken, or if there is possibly and issue in OSXVnc. I think I sent you something about this over the weekend. Also, thanks for coming on the list. This should help us get done faster so I don't have to act as mediator any more 8-) Jared |
From: Jason H. <sm...@ge...> - 2004-03-23 17:02:28
Attachments:
smime.p7s
|
Hi Jonathan, Welcome to the list! Glad to see you here! Does OSXVnc have anything similar that we should be joining? Jason Harris Lead Developer Geekspiff On Mar 23, 2004, at 9:25 AM, Jonathan Gillaspie wrote: > Hi there, > > My name is Jonathan Gillaspie and I'm the principal > developer/maintainer for the OSXvnc project. > > I've gone ahead and joined this list to help facilitate communication > between our two projects - I want to make sure users of OS X have one > of the best VNC setups available. I got the digest last night so I'll > go ahead and reply on some things for clarification. > > -- > Jonathan Gillaspie > jon...@re... > Redstone Software, Inc. > -- Makers of Platform-Independent Automation Software > -- http://www.redstonesoftware.com > > On Mar 22, 2004, at 9:04 PM, > cot...@li... wrote: > >> Send cotvnc-devel mailing list submissions to >> cot...@li... >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.sourceforge.net/lists/listinfo/cotvnc-devel >> or, via email, send a message with subject or body 'help' to >> cot...@li... >> >> You can reach the person managing the list at >> cot...@li... >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of cotvnc-devel digest..." >> >> >> Today's Topics: >> >> 1. Re: Big Huge Oops (Jared McIntyre) >> 2. Re: Big Huge Oops (Jared McIntyre) >> 3. Re: Chicken of the VNC ZRLE Encoding >> (=?ISO-8859-1?Q?S=E9bastien_Desvignes?=) >> 4. [ cotvnc-Bugs-917708 ] Strange colors with 24 bits RGB - ZRLE >> (SourceForge.net) >> 5. Re: Chicken of the VNC ZRLE Encoding (Jared McIntyre) >> >> --__--__-- >> >> Message: 1 >> Date: Sun, 21 Mar 2004 23:47:41 -0700 >> To: Jason Harris <sm...@ge...>, >> cot...@li... >> From: Jared McIntyre <jmc...@df...> >> Subject: Re: [cotvnc-devel] Big Huge Oops >> >> At 12:57 PM -0700 3/21/04, Jason Harris wrote: >>> Mime-Version: 1.0 (Apple Message framework v613) >>> Content-Type: multipart/signed; micalg=sha1; >>> boundary=Apple-Mail-24-660119039; >>> protocol="application/pkcs7-signature" >>> >>> I noticed this when I synced with the tree. Your changes are >>> looking nice so far! >>> >>> I think if possible, though, you should try to back out of them on >>> the main branch. I know that there are random people trying to >>> compile builds from it, so I'd like to keep it in a known state as >>> much as possible. I had to do a bit of tweaking to get a clean >>> build from it. >>> >>> If it helps, I've got a snapshot from before your changes. It's got >>> some changes to the ZRLE files, but everything else, I think, was >>> fresh from CVS. >>> >>> Jason >> >> Its actually labeled where the changes start, so it'll be pretty easy >> to move it back out. It'll just take time. I'm not going to be able >> to make those shifts until later in the week however. I'll update >> everyone when I do. >> >> Jared >> >> >> --__--__-- >> >> Message: 2 >> Date: Mon, 22 Mar 2004 02:32:12 -0700 >> To: cot...@li... >> From: Jared McIntyre <jmc...@df...> >> Subject: Re: [cotvnc-devel] Big Huge Oops >> >> I couldn't sleep this evening, so I took the time to revert >> everything back and migrate the new code to the correct label. All >> the new code is in GEN_2_GUI and everything else is reverted back to >> where it was before I touched it. After a cursory build and test, it >> would appear that everything is back to working the way it was. I >> did notice that the passwords weren't really sticking between >> runnings of the program, but I'm pretty sure that was the way it was >> before I started working with it (that was one of the earlier things >> I changed). >> >> Jared >> >> >> --__--__-- >> >> Message: 3 >> Date: Mon, 22 Mar 2004 22:51:54 +0100 >> From: =?ISO-8859-1?Q?S=E9bastien_Desvignes?= <bo...@op...> >> To: Jason Harris <sm...@ge...> >> Cc: cot...@li... >> Subject: [cotvnc-devel] Re: Chicken of the VNC ZRLE Encoding >> >> Jason Harris a =E9crit : >> >>> Hi Bob, >>> >>> I was wondering if you can join the Chicken development mailing >>> list=20 >>> so we can discuss this bug in a way that the other devs can see the >>> =20 >>> discussion too. The signup page is at >>> http://lists.sourceforge.net/lists/listinfo/cotvnc-devel >>> >> Done. >> >>> My current status regarding this bug is (as of this writing) on the >>> =20 >>> most recent response on the ZLIB encoding bug page at >>> >>> Can you check it out and let me know what other problems you'd seen? >>> =20 >>> Everything seems to be working fine on my end now. >>> >> Well, unfortunately, the problem isn't that simple. The problem is >> that=20 >> RealVnc doesn't behave like the other Vnc servers (OSXvnc and >> TightVnc=20 >> for example). So, my solution solves the problem with RealVnc, but >> it=20 >> breaks with the others. >> When RealVnc is set to depth 32, it uses a packed pixel size of 3 >> bytes. >> When OSXVnc (or TightVnc) is set to depth 32, it uses a packed >> pixel=20 >> size of 4 bytes. >> The correct way to solve this problem would be to detect >> specifically=20 >> RealVnc to choose the correct size for packed pixels. I don't know >> how=20 >> to do that. >> Another solution would be to ask depth 24 when the server reports >> depth=20 >> 32 and chicken is set to server native. There are other problems >> with=20 >> depth 24 (almost solved in CVS), but it should be more manageable. >> >> A+, >> Bob. >> --=20 >> <http://www.ophiuchus.org/> >> Seule la mort peut gu=E9rir la stupidit=E9. (proverbe japonais) >> Poser une question stupide est moins stupide que de rester dans >> l'ignorance de la r=E9ponse. (proverbe de Bob) >> >> >> >> --__--__-- >> >> Message: 4 >> To: no...@so... >> From: "SourceForge.net" <no...@so...> >> Date: Mon, 22 Mar 2004 13:57:23 -0800 >> Subject: [cotvnc-devel] [ cotvnc-Bugs-917708 ] Strange colors with 24 >> bits RGB - ZRLE >> >> Bugs item #917708, was opened at 2004-03-16 16:03 >> Message generated for change (Comment added) made by nobody >> You can respond by visiting: >> https://sourceforge.net/tracker/? >> func=detail&atid=507159&aid=917708&group_id=64347 >> >> Category: None >> Group: None >> Status: Pending >> Resolution: Fixed >> Priority: 5 >> Submitted By: Nobody/Anonymous (nobody) >> Assigned to: Jason Harris (smeger) >> Summary: Strange colors with 24 bits RGB - ZRLE >> >> Initial Comment: >> When I use the 24 bits RGB Pixel format and the ZRLE >> encoding, the colors are very strange. All colors seems >> to be shifted toward the cian color. >> Server : >> OSXvnc >> Server reports Version RFB 003.003 >> Transport Pixelformat: >> trueColor = YES >> bigEndian = YES >> bitsPerPixel = 32 >> depth = 24 >> maxValue(r/g/b) = (255/255/255) >> shift(r/g/b) = (24/16/8) >> >> In that case, the pixel data are packed in the most >> significant bits of the pixel, but the reader put them >> in the least signicant bits (function cvt_pixel24) >> >> -- >> bob (at) ophiuchus (dot) org >> >> ---------------------------------------------------------------------- >> >> Comment By: Nobody/Anonymous (nobody) >> Date: 2004-03-22 13:57 >> >> Message: >> Logged In: NO >> >> The function splitRGB has the same problem than the function >> cvt_pixel24. >> You fixed the function cvt_pixel24, but the function >> splitRGB is still broken. >> >> ---------------------------------------------------------------------- >> >> Comment By: Jason Harris (smeger) >> Date: 2004-03-20 18:48 >> >> Message: >> Logged In: YES >> user_id=351330 >> >> Fixed in CVS. However, Tight is broken when connecting to OSXVnc. >> Not >> sure if this is a new one or the same bug. >> >> ---------------------------------------------------------------------- >> >> You can respond by visiting: >> https://sourceforge.net/tracker/? >> func=detail&atid=507159&aid=917708&group_id=64347 >> >> >> --__--__-- >> >> Message: 5 >> Date: Mon, 22 Mar 2004 18:50:12 -0700 >> To: =?iso-8859-1?Q?S=E9bastien?= Desvignes <bo...@op...>, >> Jason Harris <sm...@ge...> >> From: Jared McIntyre <jmc...@df...> >> Subject: [cotvnc-devel] Re: Chicken of the VNC ZRLE Encoding >> Cc: cot...@li... >> >>> Well, unfortunately, the problem isn't that simple. The problem is >>> that RealVnc doesn't behave like the other Vnc servers (OSXvnc and >>> TightVnc for example). So, my solution solves the problem with >>> RealVnc, but it breaks with the others. >>> When RealVnc is set to depth 32, it uses a packed pixel size of 3 >>> bytes. >>> When OSXVnc (or TightVnc) is set to depth 32, it uses a packed pixel >>> size of 4 bytes. >>> The correct way to solve this problem would be to detect >>> specifically RealVnc to choose the correct size for packed pixels. I >>> don't know how to do that. >>> Another solution would be to ask depth 24 when the server reports >>> depth 32 and chicken is set to server native. There are other >>> problems with depth 24 (almost solved in CVS), but it should be more >>> manageable. >> >> That's definitely interesting. If that is the case, I think it may >> be an issue in Real, since I remember reading the spec a few days ago >> specifying that 24 was the top end for 3 byte. I'd have to look >> again, however, to validate. If that is the case, we should bring it >> to the attention of the RealVNC team and get their thoughts (though >> they have been less than helpful in the past). >> >> Jared >> >> >> >> --__--__-- >> >> _______________________________________________ >> cotvnc-devel mailing list >> cot...@li... >> https://lists.sourceforge.net/lists/listinfo/cotvnc-devel >> >> >> End of cotvnc-devel Digest > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > cotvnc-devel mailing list > cot...@li... > https://lists.sourceforge.net/lists/listinfo/cotvnc-devel > > |
From: Jonathan G. <jon...@re...> - 2004-03-23 17:07:27
|
Not currently, we maintain OSXvnc at our office so most of that discussion is offline. Currently we have one external developer who is "just starting" so for now I can speak for the whole OSXvnc team. -- Jonathan Gillaspie jon...@re... Redstone Software, Inc. -- Makers of Platform-Independent Automation Software -- http://www.redstonesoftware.com On Mar 23, 2004, at 10:02 AM, Jason Harris wrote: > Hi Jonathan, > > Welcome to the list! Glad to see you here! > > Does OSXVnc have anything similar that we should be joining? > > Jason Harris > Lead Developer > Geekspiff > > On Mar 23, 2004, at 9:25 AM, Jonathan Gillaspie wrote: > >> Hi there, >> >> My name is Jonathan Gillaspie and I'm the principal >> developer/maintainer for the OSXvnc project. >> >> I've gone ahead and joined this list to help facilitate communication >> between our two projects - I want to make sure users of OS X have one >> of the best VNC setups available. I got the digest last night so >> I'll go ahead and reply on some things for clarification. >> >> -- >> Jonathan Gillaspie >> jon...@re... >> Redstone Software, Inc. >> -- Makers of Platform-Independent Automation Software >> -- http://www.redstonesoftware.com >> >> On Mar 22, 2004, at 9:04 PM, >> cot...@li... wrote: >> >>> Send cotvnc-devel mailing list submissions to >>> cot...@li... >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://lists.sourceforge.net/lists/listinfo/cotvnc-devel >>> or, via email, send a message with subject or body 'help' to >>> cot...@li... >>> >>> You can reach the person managing the list at >>> cot...@li... >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of cotvnc-devel digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: Big Huge Oops (Jared McIntyre) >>> 2. Re: Big Huge Oops (Jared McIntyre) >>> 3. Re: Chicken of the VNC ZRLE Encoding >>> (=?ISO-8859-1?Q?S=E9bastien_Desvignes?=) >>> 4. [ cotvnc-Bugs-917708 ] Strange colors with 24 bits RGB - ZRLE >>> (SourceForge.net) >>> 5. Re: Chicken of the VNC ZRLE Encoding (Jared McIntyre) >>> >>> --__--__-- >>> >>> Message: 1 >>> Date: Sun, 21 Mar 2004 23:47:41 -0700 >>> To: Jason Harris <sm...@ge...>, >>> cot...@li... >>> From: Jared McIntyre <jmc...@df...> >>> Subject: Re: [cotvnc-devel] Big Huge Oops >>> >>> At 12:57 PM -0700 3/21/04, Jason Harris wrote: >>>> Mime-Version: 1.0 (Apple Message framework v613) >>>> Content-Type: multipart/signed; micalg=sha1; >>>> boundary=Apple-Mail-24-660119039; >>>> protocol="application/pkcs7-signature" >>>> >>>> I noticed this when I synced with the tree. Your changes are >>>> looking nice so far! >>>> >>>> I think if possible, though, you should try to back out of them on >>>> the main branch. I know that there are random people trying to >>>> compile builds from it, so I'd like to keep it in a known state as >>>> much as possible. I had to do a bit of tweaking to get a clean >>>> build from it. >>>> >>>> If it helps, I've got a snapshot from before your changes. It's got >>>> some changes to the ZRLE files, but everything else, I think, was >>>> fresh from CVS. >>>> >>>> Jason >>> >>> Its actually labeled where the changes start, so it'll be pretty easy >>> to move it back out. It'll just take time. I'm not going to be able >>> to make those shifts until later in the week however. I'll update >>> everyone when I do. >>> >>> Jared >>> >>> >>> --__--__-- >>> >>> Message: 2 >>> Date: Mon, 22 Mar 2004 02:32:12 -0700 >>> To: cot...@li... >>> From: Jared McIntyre <jmc...@df...> >>> Subject: Re: [cotvnc-devel] Big Huge Oops >>> >>> I couldn't sleep this evening, so I took the time to revert >>> everything back and migrate the new code to the correct label. All >>> the new code is in GEN_2_GUI and everything else is reverted back to >>> where it was before I touched it. After a cursory build and test, it >>> would appear that everything is back to working the way it was. I >>> did notice that the passwords weren't really sticking between >>> runnings of the program, but I'm pretty sure that was the way it was >>> before I started working with it (that was one of the earlier things >>> I changed). >>> >>> Jared >>> >>> >>> --__--__-- >>> >>> Message: 3 >>> Date: Mon, 22 Mar 2004 22:51:54 +0100 >>> From: =?ISO-8859-1?Q?S=E9bastien_Desvignes?= <bo...@op...> >>> To: Jason Harris <sm...@ge...> >>> Cc: cot...@li... >>> Subject: [cotvnc-devel] Re: Chicken of the VNC ZRLE Encoding >>> >>> Jason Harris a =E9crit : >>> >>>> Hi Bob, >>>> >>>> I was wondering if you can join the Chicken development mailing >>>> list=20 >>>> so we can discuss this bug in a way that the other devs can see >>>> the =20 >>>> discussion too. The signup page is at >>>> http://lists.sourceforge.net/lists/listinfo/cotvnc-devel >>>> >>> Done. >>> >>>> My current status regarding this bug is (as of this writing) on the >>>> =20 >>>> most recent response on the ZLIB encoding bug page at >>>> >>>> Can you check it out and let me know what other problems you'd >>>> seen? =20 >>>> Everything seems to be working fine on my end now. >>>> >>> Well, unfortunately, the problem isn't that simple. The problem is >>> that=20 >>> RealVnc doesn't behave like the other Vnc servers (OSXvnc and >>> TightVnc=20 >>> for example). So, my solution solves the problem with RealVnc, but >>> it=20 >>> breaks with the others. >>> When RealVnc is set to depth 32, it uses a packed pixel size of 3 >>> bytes. >>> When OSXVnc (or TightVnc) is set to depth 32, it uses a packed >>> pixel=20 >>> size of 4 bytes. >>> The correct way to solve this problem would be to detect >>> specifically=20 >>> RealVnc to choose the correct size for packed pixels. I don't know >>> how=20 >>> to do that. >>> Another solution would be to ask depth 24 when the server reports >>> depth=20 >>> 32 and chicken is set to server native. There are other problems >>> with=20 >>> depth 24 (almost solved in CVS), but it should be more manageable. >>> >>> A+, >>> Bob. >>> --=20 >>> <http://www.ophiuchus.org/> >>> Seule la mort peut gu=E9rir la stupidit=E9. (proverbe japonais) >>> Poser une question stupide est moins stupide que de rester dans >>> l'ignorance de la r=E9ponse. (proverbe de Bob) >>> >>> >>> >>> --__--__-- >>> >>> Message: 4 >>> To: no...@so... >>> From: "SourceForge.net" <no...@so...> >>> Date: Mon, 22 Mar 2004 13:57:23 -0800 >>> Subject: [cotvnc-devel] [ cotvnc-Bugs-917708 ] Strange colors with >>> 24 bits RGB - ZRLE >>> >>> Bugs item #917708, was opened at 2004-03-16 16:03 >>> Message generated for change (Comment added) made by nobody >>> You can respond by visiting: >>> https://sourceforge.net/tracker/? >>> func=detail&atid=507159&aid=917708&group_id=64347 >>> >>> Category: None >>> Group: None >>> Status: Pending >>> Resolution: Fixed >>> Priority: 5 >>> Submitted By: Nobody/Anonymous (nobody) >>> Assigned to: Jason Harris (smeger) >>> Summary: Strange colors with 24 bits RGB - ZRLE >>> >>> Initial Comment: >>> When I use the 24 bits RGB Pixel format and the ZRLE >>> encoding, the colors are very strange. All colors seems >>> to be shifted toward the cian color. >>> Server : >>> OSXvnc >>> Server reports Version RFB 003.003 >>> Transport Pixelformat: >>> trueColor = YES >>> bigEndian = YES >>> bitsPerPixel = 32 >>> depth = 24 >>> maxValue(r/g/b) = (255/255/255) >>> shift(r/g/b) = (24/16/8) >>> >>> In that case, the pixel data are packed in the most >>> significant bits of the pixel, but the reader put them >>> in the least signicant bits (function cvt_pixel24) >>> >>> -- >>> bob (at) ophiuchus (dot) org >>> >>> --------------------------------------------------------------------- >>> - >>> >>> Comment By: Nobody/Anonymous (nobody) >>> Date: 2004-03-22 13:57 >>> >>> Message: >>> Logged In: NO >>> >>> The function splitRGB has the same problem than the function >>> cvt_pixel24. >>> You fixed the function cvt_pixel24, but the function >>> splitRGB is still broken. >>> >>> --------------------------------------------------------------------- >>> - >>> >>> Comment By: Jason Harris (smeger) >>> Date: 2004-03-20 18:48 >>> >>> Message: >>> Logged In: YES >>> user_id=351330 >>> >>> Fixed in CVS. However, Tight is broken when connecting to OSXVnc. >>> Not >>> sure if this is a new one or the same bug. >>> >>> --------------------------------------------------------------------- >>> - >>> >>> You can respond by visiting: >>> https://sourceforge.net/tracker/? >>> func=detail&atid=507159&aid=917708&group_id=64347 >>> >>> >>> --__--__-- >>> >>> Message: 5 >>> Date: Mon, 22 Mar 2004 18:50:12 -0700 >>> To: =?iso-8859-1?Q?S=E9bastien?= Desvignes <bo...@op...>, >>> Jason Harris <sm...@ge...> >>> From: Jared McIntyre <jmc...@df...> >>> Subject: [cotvnc-devel] Re: Chicken of the VNC ZRLE Encoding >>> Cc: cot...@li... >>> >>>> Well, unfortunately, the problem isn't that simple. The problem is >>>> that RealVnc doesn't behave like the other Vnc servers (OSXvnc and >>>> TightVnc for example). So, my solution solves the problem with >>>> RealVnc, but it breaks with the others. >>>> When RealVnc is set to depth 32, it uses a packed pixel size of 3 >>>> bytes. >>>> When OSXVnc (or TightVnc) is set to depth 32, it uses a packed pixel >>>> size of 4 bytes. >>>> The correct way to solve this problem would be to detect >>>> specifically RealVnc to choose the correct size for packed pixels. I >>>> don't know how to do that. >>>> Another solution would be to ask depth 24 when the server reports >>>> depth 32 and chicken is set to server native. There are other >>>> problems with depth 24 (almost solved in CVS), but it should be more >>>> manageable. >>> >>> That's definitely interesting. If that is the case, I think it may >>> be an issue in Real, since I remember reading the spec a few days ago >>> specifying that 24 was the top end for 3 byte. I'd have to look >>> again, however, to validate. If that is the case, we should bring it >>> to the attention of the RealVNC team and get their thoughts (though >>> they have been less than helpful in the past). >>> >>> Jared >>> >>> >>> >>> --__--__-- >>> >>> _______________________________________________ >>> cotvnc-devel mailing list >>> cot...@li... >>> https://lists.sourceforge.net/lists/listinfo/cotvnc-devel >>> >>> >>> End of cotvnc-devel Digest >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IBM Linux Tutorials >> Free Linux tutorial presented by Daniel Robbins, President and CEO of >> GenToo technologies. Learn everything from fundamentals to system >> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >> _______________________________________________ >> cotvnc-devel mailing list >> cot...@li... >> https://lists.sourceforge.net/lists/listinfo/cotvnc-devel >> >> |