libvncserver-common — Common questions and all

Re: [Libvncserver-common] LibVNC* Python bindings - GSoC2016

[Christian B. <don...@fr...>]

Am Wed, 3 Feb 2016 00:38:30 +0200
schrieb Fotis Tsamis <ft...@gm...>:

> Well, that's great news!
> The organizations application period is 8 - 19 February 19:00 UTC, so
> there is enough time. I'm glad we started early!

Hi folks,

I just started the application process - in the meantime, there's
https://docs.google.com/document/d/18M0t8ZkEizfQT-87RnG88gqywSeYP-l36_FCnYMLO1c/edit?usp=sharing
for sketching out ideas.

Cheers,

   Christian

> 
> Regards,
> Fotis
> 
> 2016-02-01 14:01 GMT+02:00 Christian Beier <don...@fr...>:
> > Am Mon, 1 Feb 2016 07:58:12 +0100 (CET)
> > schrieb Johannes Schindelin <Joh...@gm...>:
> >
> >> Hi Christian,
> >>
> >> On Sun, 31 Jan 2016, Christian Beier wrote:
> >>
> >> > Only thing I can't do is be backup-mentor. Maybe dscho (CC'ed) can fill
> >> > this position, if it's really just about formal backup?
> >>
> >> Sure!
> >>
> >
> >
> > Cool! Then I'll prep the google registration.
> >
> > Cheers,
> >
> >    C.

Re: [Libvncserver-common] LibVNC* Python bindings - GSoC2016

[Fotis T. <ft...@gm...>]

Well, that's great news!
The organizations application period is 8 - 19 February 19:00 UTC, so
there is enough time. I'm glad we started early!

Regards,
Fotis

2016-02-01 14:01 GMT+02:00 Christian Beier <don...@fr...>:
> Am Mon, 1 Feb 2016 07:58:12 +0100 (CET)
> schrieb Johannes Schindelin <Joh...@gm...>:
>
>> Hi Christian,
>>
>> On Sun, 31 Jan 2016, Christian Beier wrote:
>>
>> > Only thing I can't do is be backup-mentor. Maybe dscho (CC'ed) can fill
>> > this position, if it's really just about formal backup?
>>
>> Sure!
>>
>
>
> Cool! Then I'll prep the google registration.
>
> Cheers,
>
>    C.

Re: [Libvncserver-common] LibVNC* Python bindings - GSoC2016

[Christian B. <don...@fr...>]

Am Mon, 1 Feb 2016 07:58:12 +0100 (CET)
schrieb Johannes Schindelin <Joh...@gm...>:

> Hi Christian,
> 
> On Sun, 31 Jan 2016, Christian Beier wrote:
> 
> > Only thing I can't do is be backup-mentor. Maybe dscho (CC'ed) can fill
> > this position, if it's really just about formal backup?
> 
> Sure!
> 


Cool! Then I'll prep the google registration.

Cheers,

   C.

Re: [Libvncserver-common] LibVNC* Python bindings - GSoC2016

[Johannes S. <Joh...@gm...>]

Hi Christian,

On Sun, 31 Jan 2016, Christian Beier wrote:

> Only thing I can't do is be backup-mentor. Maybe dscho (CC'ed) can fill
> this position, if it's really just about formal backup?

Sure!

Ciao,
Johannes

Re: [Libvncserver-common] LibVNC* Python bindings - GSoC2016

[Christian B. <don...@fr...>]

Hi Fotis,

Just back from holidays - now found some time for an answer.

Thinking a bit more in depth about this, I think I'll be able to do the google
registration and some email developer support as well. Also, sending feedback
and evaluations to google is something I can set aside some time for.

Only thing I can't do is be backup-mentor. Maybe dscho (CC'ed) can fill this
position, if it's really just about formal backup?

Cheers,

   Christian	



Am Sat, 9 Jan 2016 04:23:18 +0200
schrieb Fotis Tsamis <ft...@gm...>:

> Hello Christian,
> 
> I'm glad you find this interesting. Regarding the time required for
> mentors, it highly depends on the idea itself and the chosen student's
> understanding of the project's codebase. Google estimates in its FAQ that
> mentors need about 5 hours per student per week.
> 
> On the Python bindings idea, I have plans to work on it either as part of
> GSoC or independently, if for some reason we won't make it to GSoC. So for
> this particular idea, I assume that all I would need would be possibly a
> few mails exchanged for opinions or clarifications. Other students working
> on other ideas could need quite a bit more guidance.
> 
> A mentor can be anyone who has commited code on the project, and you need
> at least 2 people as administrators and/or mentors to be able to apply as a
> "Mentoring organization". There is a pretty extensive FAQ for mentoring
> organizations at [1] if you wish to give it a look.
> 
> Also, keep in mind that there are certain milestones (with already set
> dates at [2]) at which mentors are required to send feedback (evaluations)
> to Google about how the student is going with his/her assigned idea,
> missing those could result in confusion. The same applies on the student
> side, of course.
> 
> My opinion is that if you are only 2 active people working on LibVNC, both
> with very limited time, it could be challenging to mentor 2 ideas (let
> alone more than 2), taking in account that you would also have to do the
> administrators' tasks (i.e. creating the ideas pages, actually applying to
> Google, quickly responding to Google's inquiries, etc) but it is doable.
> 
> [1]
> https://developers.google.com/open-source/gsoc/faq#mentoring_organizations
> [2] https://developers.google.com/open-source/gsoc/timeline
> 
> Although a bit long, I hope this message was helpful!
> 
> Happy New Year,
> Fotis
> 
> 2016-01-08 19:09 GMT+02:00 Christian Beier <
> chr...@go...>:
> 
> >
> > Hi Fotis,
> >
> > Sorry for the long delay, I've been quite busy with new year's festivities
> > and
> > then real work (tm) consuming all my time.
> >
> > That said, I am definitely open to your idea and I've got some ideas for
> > LibVNC
> > improvement as well, only thing is that I (and Dscho as well I guess) am
> > quite
> > busy with my money-earning job. Do you (or anybody you know) know
> > time-consuming that mentoring would be? (I could spend a few hours a week
> > but
> > that's about it...)
> >
> > Generally, I think it's quite tempting ;-)
> >
> > Thanks for writing in!
> >
> >    Christian
> >
> >
> > Am Tue, 29 Dec 2015 00:29:04 +0200
> > schrieb Fotis Tsamis <ft...@gm...>:
> >
> > > Hello,
> > >
> > > My name is Fotis and I am an IT student. I am currently studying
> > > libvncserver/client code in order to create bindings for Python (and
> > > possibly for other scripting languages) by using SWIG. I am a developer
> > of
> > > an open source project named Epoptes [1], which would benefit from
> > LibVNC*
> > > Python bindings and thus my interest on this.
> > >
> > > I noticed that Google announced their 2016 GSoC program and I was
> > wondering
> > > if you (the libvncserver/client devs) are interested on applying to it
> > as a
> > > mentoring organization. From your side, that would mean assigning a
> > couple
> > > of persons as administrators, who would be the contacts with Google,
> > > creating an Ideas page, (hopefully) containing this and any other
> > possible
> > > ideas you might have for student projects, and assigning a mentor per
> > idea
> > > who would supervise/assist with its implementation. You can see a
> > timeline
> > > and a FAQ for GSoC 2016 at [2],[3].
> > >
> > > In the case you are interested in applying as a mentoring organization,
> > and
> > > you find the python bindings idea interesting, I'd really love to also
> > > apply as a student on this idea.
> > >
> > > Best Regards,
> > > Fotis
> > >
> > > [1] http://www.epoptes.org
> > > [2] https://developers.google.com/open-source/gsoc/timeline
> > > [3] https://developers.google.com/open-source/gsoc/faq
> >
> >

Re: [Libvncserver-common] LibVNC* Python bindings - GSoC2016

[Fotis T. <ft...@gm...>]

Hello Christian,

I'm glad you find this interesting. Regarding the time required for
mentors, it highly depends on the idea itself and the chosen student's
understanding of the project's codebase. Google estimates in its FAQ that
mentors need about 5 hours per student per week.

On the Python bindings idea, I have plans to work on it either as part of
GSoC or independently, if for some reason we won't make it to GSoC. So for
this particular idea, I assume that all I would need would be possibly a
few mails exchanged for opinions or clarifications. Other students working
on other ideas could need quite a bit more guidance.

A mentor can be anyone who has commited code on the project, and you need
at least 2 people as administrators and/or mentors to be able to apply as a
"Mentoring organization". There is a pretty extensive FAQ for mentoring
organizations at [1] if you wish to give it a look.

Also, keep in mind that there are certain milestones (with already set
dates at [2]) at which mentors are required to send feedback (evaluations)
to Google about how the student is going with his/her assigned idea,
missing those could result in confusion. The same applies on the student
side, of course.

My opinion is that if you are only 2 active people working on LibVNC, both
with very limited time, it could be challenging to mentor 2 ideas (let
alone more than 2), taking in account that you would also have to do the
administrators' tasks (i.e. creating the ideas pages, actually applying to
Google, quickly responding to Google's inquiries, etc) but it is doable.

[1]
https://developers.google.com/open-source/gsoc/faq#mentoring_organizations
[2] https://developers.google.com/open-source/gsoc/timeline

Although a bit long, I hope this message was helpful!

Happy New Year,
Fotis

2016-01-08 19:09 GMT+02:00 Christian Beier <
chr...@go...>:

>
> Hi Fotis,
>
> Sorry for the long delay, I've been quite busy with new year's festivities
> and
> then real work (tm) consuming all my time.
>
> That said, I am definitely open to your idea and I've got some ideas for
> LibVNC
> improvement as well, only thing is that I (and Dscho as well I guess) am
> quite
> busy with my money-earning job. Do you (or anybody you know) know
> time-consuming that mentoring would be? (I could spend a few hours a week
> but
> that's about it...)
>
> Generally, I think it's quite tempting ;-)
>
> Thanks for writing in!
>
>    Christian
>
>
> Am Tue, 29 Dec 2015 00:29:04 +0200
> schrieb Fotis Tsamis <ft...@gm...>:
>
> > Hello,
> >
> > My name is Fotis and I am an IT student. I am currently studying
> > libvncserver/client code in order to create bindings for Python (and
> > possibly for other scripting languages) by using SWIG. I am a developer
> of
> > an open source project named Epoptes [1], which would benefit from
> LibVNC*
> > Python bindings and thus my interest on this.
> >
> > I noticed that Google announced their 2016 GSoC program and I was
> wondering
> > if you (the libvncserver/client devs) are interested on applying to it
> as a
> > mentoring organization. From your side, that would mean assigning a
> couple
> > of persons as administrators, who would be the contacts with Google,
> > creating an Ideas page, (hopefully) containing this and any other
> possible
> > ideas you might have for student projects, and assigning a mentor per
> idea
> > who would supervise/assist with its implementation. You can see a
> timeline
> > and a FAQ for GSoC 2016 at [2],[3].
> >
> > In the case you are interested in applying as a mentoring organization,
> and
> > you find the python bindings idea interesting, I'd really love to also
> > apply as a student on this idea.
> >
> > Best Regards,
> > Fotis
> >
> > [1] http://www.epoptes.org
> > [2] https://developers.google.com/open-source/gsoc/timeline
> > [3] https://developers.google.com/open-source/gsoc/faq
>
>

Re: [Libvncserver-common] LibVNC* Python bindings - GSoC2016

[Christian B. <chr...@go...>]

Hi Fotis,

Sorry for the long delay, I've been quite busy with new year's festivities and
then real work (tm) consuming all my time.

That said, I am definitely open to your idea and I've got some ideas for LibVNC
improvement as well, only thing is that I (and Dscho as well I guess) am quite
busy with my money-earning job. Do you (or anybody you know) know
time-consuming that mentoring would be? (I could spend a few hours a week but
that's about it...)

Generally, I think it's quite tempting ;-)

Thanks for writing in!

   Christian


Am Tue, 29 Dec 2015 00:29:04 +0200
schrieb Fotis Tsamis <ft...@gm...>:

> Hello,
> 
> My name is Fotis and I am an IT student. I am currently studying
> libvncserver/client code in order to create bindings for Python (and
> possibly for other scripting languages) by using SWIG. I am a developer of
> an open source project named Epoptes [1], which would benefit from LibVNC*
> Python bindings and thus my interest on this.
> 
> I noticed that Google announced their 2016 GSoC program and I was wondering
> if you (the libvncserver/client devs) are interested on applying to it as a
> mentoring organization. From your side, that would mean assigning a couple
> of persons as administrators, who would be the contacts with Google,
> creating an Ideas page, (hopefully) containing this and any other possible
> ideas you might have for student projects, and assigning a mentor per idea
> who would supervise/assist with its implementation. You can see a timeline
> and a FAQ for GSoC 2016 at [2],[3].
> 
> In the case you are interested in applying as a mentoring organization, and
> you find the python bindings idea interesting, I'd really love to also
> apply as a student on this idea.
> 
> Best Regards,
> Fotis
> 
> [1] http://www.epoptes.org
> [2] https://developers.google.com/open-source/gsoc/timeline
> [3] https://developers.google.com/open-source/gsoc/faq

[Libvncserver-common] LibVNC* Python bindings - GSoC2016

[Fotis T. <ft...@gm...>]

Hello,

My name is Fotis and I am an IT student. I am currently studying
libvncserver/client code in order to create bindings for Python (and
possibly for other scripting languages) by using SWIG. I am a developer of
an open source project named Epoptes [1], which would benefit from LibVNC*
Python bindings and thus my interest on this.

I noticed that Google announced their 2016 GSoC program and I was wondering
if you (the libvncserver/client devs) are interested on applying to it as a
mentoring organization. From your side, that would mean assigning a couple
of persons as administrators, who would be the contacts with Google,
creating an Ideas page, (hopefully) containing this and any other possible
ideas you might have for student projects, and assigning a mentor per idea
who would supervise/assist with its implementation. You can see a timeline
and a FAQ for GSoC 2016 at [2],[3].

In the case you are interested in applying as a mentoring organization, and
you find the python bindings idea interesting, I'd really love to also
apply as a student on this idea.

Best Regards,
Fotis

[1] http://www.epoptes.org
[2] https://developers.google.com/open-source/gsoc/timeline
[3] https://developers.google.com/open-source/gsoc/faq

[Libvncserver-common] Set up libvncserver with secure connection (ssl/tls)

[Andreas S. <sch...@gm...>]

Hi,

I use the libvncserver library for the remote control of an embedded
device.
Currently I've the following setup:

   - Server with password auth and possibility to tunnel a NAT with
   connection over the UltraVNC repeater

I would like to establish a secure connection to the server, but I don't
find a solution.

I tried to enable websockets to establish a secure connection, but
everything I tried don't work.

How can I enable websockets. The define LIBVNCSERVER_WITH_WEBSOCKETS is not
defined in my project.

I use the following configure command:
./configure \
        --host=$(TARGET_BUILD) --build=i686-pc-linux-gnu
--prefix=$(PRJROOT)/syslibs/usr/local/$(TARGET_BUILD)/sysroot/usr \
        --disable-static --enable-shared \
        --with-crypto --with-ssl --without-gnutls --without-gcrypt \
        --with-sdl-config=/bin/false \
        --without-v4l --with-libz --with-zlib --with-pic \
        --with-jpeg --with-png --without-avahi --without-ipv6 )

Which libraries (attributes) are needed to enable websockets or is there
another option to use openssl to make a secure connection?

Re: [Libvncserver-common] VNC for Wayland

[Mauro C. <mco...@so...>]

Thanks Christian,
I had already seen that page.
Unfortunately the "Proof of concept http://aleksandarjovanov.blogspot.de/2012/10/having-fun-with-gnome-shell.html" seems to have vanished in nowhere land (at least I was unable to find it).

I'll keep You posted, but it doesn't look good, unfortunately.

Screen grabbing is nowhere part of Wayland specs and relies on compositor extensions (mostly diverging).

If I manage to cobble up something for my compositor it might not work on other ones.

Regards
Mauro

----- Original Message -----
> Am Wed, 20 May 2015 10:20:16 +0000
> schrieb mco...@us...:
> 
> > 
> > 
> > Hi Christian,
> > sorry to disturb You directly, please bear with me.
> > 
> > I need to implement a VNC (or other Remote Desktop) server capability
> > for an embedded product (ARM+Wayland, *no* Xlib available). I
> > understand there's some proof-of-concept available, but I couldn't
> > find it. Can You point me in the right direction, please?
> > 
> > Many Thanks in Advance
> > Mauro Condarelli
> 
> 
> Look what I found: https://github.com/LibVNC/x11vnc/issues/5
> 
> If you can hack up something for x11vnc (which is not really
> X11-centric at all), that'd be cool!
> 
> HTH,
> 
>    C.
> 

Re: [Libvncserver-common] VNC for Wayland

[Christian B. <don...@fr...>]

Am Wed, 20 May 2015 10:20:16 +0000
schrieb mco...@us...:

> 
> 
> Hi Christian,
> sorry to disturb You directly, please bear with me.
> 
> I need to implement a VNC (or other Remote Desktop) server capability
> for an embedded product (ARM+Wayland, *no* Xlib available). I
> understand there's some proof-of-concept available, but I couldn't
> find it. Can You point me in the right direction, please?
> 
> Many Thanks in Advance
> Mauro Condarelli


Look what I found: https://github.com/LibVNC/x11vnc/issues/5

If you can hack up something for x11vnc (which is not really
X11-centric at all), that'd be cool!

HTH,

   C.

Re: [Libvncserver-common] VNC for Wayland

[Christian B. <don...@fr...>]

Am Wed, 20 May 2015 10:20:16 +0000
schrieb mco...@us...:

> 
> 
> Hi Christian,
> sorry to disturb You directly, please bear with me.
> 
> I need to implement a VNC (or other Remote Desktop) server capability
> for an embedded product (ARM+Wayland, *no* Xlib available). I
> understand there's some proof-of-concept available, but I couldn't
> find it. Can You point me in the right direction, please?
> 
> Many Thanks in Advance
> Mauro Condarelli
> 

Hi Mauro,

The example code for a really simple memory-region exporting is
in /examples. Problem with wayland is how to get the framebuffer
contents. AFAIK there is no standard way of doing this (yet). Weston
(*not* wayland itself) has a snapshot interface, as does gnome-shell.
If you happen to find a std wayland way, pls let us know.

Cheers,

   Christian

Re: [Libvncserver-common] libvncserver

[BoJing W. <198...@16...>]

Dear Christian

Do you have facebook number or skype ?









|
NameBoJing Wang
198...@16...
Organization:
Address:
Telephone:
手机：15840958489
|

扫描该二维码，可以将电子名片迅速保存到手机 使用帮助

|



At 2015-05-20 13:51:55, "BoJing Wang" <198...@16...> wrote:
>Dear .<br/>I have fixed this problem, the tight compress get in this problem. i set zlib compress, it ok!<br/><br/>I have other problem, hope you can relay me.<br/><br/>rfbProcessEvents -&gt; rfbCheckFds.<br/><br/>why  dont socket connect client once. but disconnect/conect client eveyone cycle. <br/>  <br/>vncserver updatescreen rate is so low. how can i make updatescreen quickly like miracast/mhl?
>At 2015-05-19 23:13:43, "Christian Beier" <don...@fr...> wrote:
>>
>>What's the problem, actually?
>>
>>Am Tue, 12 May 2015 14:35:51 +0800 (CST)
>>schrieb "BoJing Wang" <198...@16...>:
>>
>>> 
>>> 
>>> I am sorry to write email to you , I download your code of libvncserver
>>> but i cannot run it, hope you  can help me!!!! thank you.
>>> I look forward your reply.
>>> 
>>> android server log:
>>> 130|root@android:/data/local # ./androidvncserver                             
>>> Initializing grabber method...
>>> --Loading flinger native lib--
>>> Loading lib: /data/data/org.onaips.vnc/lib/libdvnc_flinger_sdk17.so
>>> AKI1
>>> --Initializing gingerbread access method--
>>> width:720, height:1280AKII12AKI2
>>> Initializing virtual keyboard and touch device...
>>> ---Initializing uinput...---
>>> Initializing VNC server:
>>>     width:  720
>>>     height: 1280
>>>     bpp:    32
>>>     port:   5901
>>> Colourmap_rgba=0:8:16:24    lenght=8:8:8:8
>>> 12/05/2015 01:08:26 Listening for VNC connections on TCP port 5901
>>> 12/05/2015 01:08:26 Listening for HTTP connections on TCP port 5801
>>> 12/05/2015 01:08:26   URL http://localhost:5801
>>> Starting IPC connection...binded to port 13132
>>> Waiting for a connection
>>> 12/05/2015 00:55:49 httpd: get '' for 192.168.1.100
>>> 12/05/2015 00:55:49 httpd: defaulting to 'index.vnc'
>>> 12/05/2015 00:55:49 httpProcessInput: open: No such file or directory
>>> 12/05/2015 00:55:49 httpd: get 'favicon.ico' for 192.168.1.100
>>> 12/05/2015 00:55:49 httpProcessInput: open: No such file or directory
>>> 12/05/2015 00:56:04 Got connection from client 192.168.1.100
>>> 12/05/2015 00:55:49 httpd: get 'favicon.ico' for 192.168.1.100
>>> 12/05/2015 00:55:49 httpProcessInput: open: No such file or directory
>>> 12/05/2015 00:56:04   other clients:
>>> 12/05/2015 00:56:05 Normal socket connection
>>> 12/05/2015 00:56:05 Client Protocol Version 3.8
>>> 12/05/2015 00:56:05 Protocol version sent 3.8, using 3.8
>>> 12/05/2015 00:56:05 rfbProcessClientSecurityType: executing handler for type 1
>>> 12/05/2015 00:56:05 rfbProcessClientSecurityType: returning securityResult
>>> for client rfb version >= 3.8 12/05/2015 00:56:05 Pixel format for client
>>> 192.168.1.100: 12/05/2015 00:56:05   32 bpp, depth 24, little endian
>>> 12/05/2015 00:56:05   true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
>>> 12/05/2015 00:56:05 Using compression level 1 for client 192.168.1.100
>>> 12/05/2015 00:56:05 Using image quality level 6 for client 192.168.1.100
>>> 12/05/2015 00:56:05 Using JPEG subsampling 0, Q79 for client 192.168.1.100
>>> 12/05/2015 00:56:05 Enabling X-style cursor updates for client 192.168.1.100
>>> 12/05/2015 00:56:05 Enabling full-color cursor updates for client
>>> 192.168.1.100 12/05/2015 00:56:05 Enabling cursor position updates for client
>>> 192.168.1.100 12/05/2015 00:56:05 Enabling LastRect protocol extension for
>>> client 192.168.1.100 12/05/2015 00:56:05 Using tight encoding for client
>>> 192.168.1.100 Segmentation fault
>>> 139|root@android:/data/local #
>>> 130|root@android:/data/local #
>>> 
>>> vncviewer log:
>>> wangbojing@wangbojing-PC:/mnt/android-source/jb4.2.1$ vncviewer
>>> 192.168.1.101:5901 Connected to RFB server, using protocol version 3.8
>>> No authentication needed
>>> Authentication successful
>>> Desktop name "Android"
>>> VNC server default format:
>>>   32 bits per pixel.
>>>   Least significant byte first in each pixel.
>>>   True colour: max red 255 green 255 blue 255, shift red 0 green 8 blue 16
>>> Warning: Cannot convert string "-*-helvetica-bold-r-*-*-16-*-*-*-*-*-*-*" to
>>> type FontStruct Using default colormap which is TrueColor.  Pixel format:
>>>   32 bits per pixel.
>>>   Least significant byte first in each pixel.
>>>   True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
>>> vncviewer: VNC server closed connection
>>> wangbojing@wangbojing-PC:/mnt/android-source/jb4.2.1$
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> |
>>> NameBoJing Wang
>>> 198...@16...
>>> Organization:
>>> Address:
>>> Telephone:
>>> 手机：15840958489
>>> |
>>> 
>>> 扫描该二维码，可以将电子名片迅速保存到手机 使用帮助
>>> 
>>> |

Re: [Libvncserver-common] libvncserver

[BoJing W. <198...@16...>]

Dear .
I have fixed this problem, the tight compress get in this problem. i set zlib compress, it ok!


I have other problem, hope you can relay me.


rfbProcessEvents -> rfbCheckFds.


why  dont socket connect client once. but disconnect/conect client eveyone cycle.


vncserver updatescreen rate is so low. how can i make updatescreen quickly like miracast/mhl ?






|
NameBoJing Wang
198...@16...
Organization:
Address:
Telephone:
手机：15840958489
|

扫描该二维码，可以将电子名片迅速保存到手机 使用帮助

|



At 2015-05-20 13:51:55, "BoJing Wang" <198...@16...> wrote:
>Dear .<br/>I have fixed this problem, the tight compress get in this problem. i set zlib compress, it ok!<br/><br/>I have other problem, hope you can relay me.<br/><br/>rfbProcessEvents -&gt; rfbCheckFds.<br/><br/>why  dont socket connect client once. but disconnect/conect client eveyone cycle. <br/>  <br/>vncserver updatescreen rate is so low. how can i make updatescreen quickly like miracast/mhl?
>At 2015-05-19 23:13:43, "Christian Beier" <don...@fr...> wrote:
>>
>>What's the problem, actually?
>>
>>Am Tue, 12 May 2015 14:35:51 +0800 (CST)
>>schrieb "BoJing Wang" <198...@16...>:
>>
>>> 
>>> 
>>> I am sorry to write email to you , I download your code of libvncserver
>>> but i cannot run it, hope you  can help me!!!! thank you.
>>> I look forward your reply.
>>> 
>>> android server log:
>>> 130|root@android:/data/local # ./androidvncserver                             
>>> Initializing grabber method...
>>> --Loading flinger native lib--
>>> Loading lib: /data/data/org.onaips.vnc/lib/libdvnc_flinger_sdk17.so
>>> AKI1
>>> --Initializing gingerbread access method--
>>> width:720, height:1280AKII12AKI2
>>> Initializing virtual keyboard and touch device...
>>> ---Initializing uinput...---
>>> Initializing VNC server:
>>>     width:  720
>>>     height: 1280
>>>     bpp:    32
>>>     port:   5901
>>> Colourmap_rgba=0:8:16:24    lenght=8:8:8:8
>>> 12/05/2015 01:08:26 Listening for VNC connections on TCP port 5901
>>> 12/05/2015 01:08:26 Listening for HTTP connections on TCP port 5801
>>> 12/05/2015 01:08:26   URL http://localhost:5801
>>> Starting IPC connection...binded to port 13132
>>> Waiting for a connection
>>> 12/05/2015 00:55:49 httpd: get '' for 192.168.1.100
>>> 12/05/2015 00:55:49 httpd: defaulting to 'index.vnc'
>>> 12/05/2015 00:55:49 httpProcessInput: open: No such file or directory
>>> 12/05/2015 00:55:49 httpd: get 'favicon.ico' for 192.168.1.100
>>> 12/05/2015 00:55:49 httpProcessInput: open: No such file or directory
>>> 12/05/2015 00:56:04 Got connection from client 192.168.1.100
>>> 12/05/2015 00:55:49 httpd: get 'favicon.ico' for 192.168.1.100
>>> 12/05/2015 00:55:49 httpProcessInput: open: No such file or directory
>>> 12/05/2015 00:56:04   other clients:
>>> 12/05/2015 00:56:05 Normal socket connection
>>> 12/05/2015 00:56:05 Client Protocol Version 3.8
>>> 12/05/2015 00:56:05 Protocol version sent 3.8, using 3.8
>>> 12/05/2015 00:56:05 rfbProcessClientSecurityType: executing handler for type 1
>>> 12/05/2015 00:56:05 rfbProcessClientSecurityType: returning securityResult
>>> for client rfb version >= 3.8 12/05/2015 00:56:05 Pixel format for client
>>> 192.168.1.100: 12/05/2015 00:56:05   32 bpp, depth 24, little endian
>>> 12/05/2015 00:56:05   true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
>>> 12/05/2015 00:56:05 Using compression level 1 for client 192.168.1.100
>>> 12/05/2015 00:56:05 Using image quality level 6 for client 192.168.1.100
>>> 12/05/2015 00:56:05 Using JPEG subsampling 0, Q79 for client 192.168.1.100
>>> 12/05/2015 00:56:05 Enabling X-style cursor updates for client 192.168.1.100
>>> 12/05/2015 00:56:05 Enabling full-color cursor updates for client
>>> 192.168.1.100 12/05/2015 00:56:05 Enabling cursor position updates for client
>>> 192.168.1.100 12/05/2015 00:56:05 Enabling LastRect protocol extension for
>>> client 192.168.1.100 12/05/2015 00:56:05 Using tight encoding for client
>>> 192.168.1.100 Segmentation fault
>>> 139|root@android:/data/local #
>>> 130|root@android:/data/local #
>>> 
>>> vncviewer log:
>>> wangbojing@wangbojing-PC:/mnt/android-source/jb4.2.1$ vncviewer
>>> 192.168.1.101:5901 Connected to RFB server, using protocol version 3.8
>>> No authentication needed
>>> Authentication successful
>>> Desktop name "Android"
>>> VNC server default format:
>>>   32 bits per pixel.
>>>   Least significant byte first in each pixel.
>>>   True colour: max red 255 green 255 blue 255, shift red 0 green 8 blue 16
>>> Warning: Cannot convert string "-*-helvetica-bold-r-*-*-16-*-*-*-*-*-*-*" to
>>> type FontStruct Using default colormap which is TrueColor.  Pixel format:
>>>   32 bits per pixel.
>>>   Least significant byte first in each pixel.
>>>   True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
>>> vncviewer: VNC server closed connection
>>> wangbojing@wangbojing-PC:/mnt/android-source/jb4.2.1$
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> |
>>> NameBoJing Wang
>>> 198...@16...
>>> Organization:
>>> Address:
>>> Telephone:
>>> 手机：15840958489
>>> |
>>> 
>>> 扫描该二维码，可以将电子名片迅速保存到手机 使用帮助
>>> 
>>> |

Re: [Libvncserver-common] libvncserver

[BoJing W. <198...@16...>]

Dear .<br/>I have fixed this problem, the tight compress get in this problem. i set zlib compress, it ok!<br/><br/>I have other problem, hope you can relay me.<br/><br/>rfbProcessEvents -&gt; rfbCheckFds.<br/><br/>why  dont socket connect client once. but disconnect/conect client eveyone cycle. <br/>  <br/>vncserver updatescreen rate is so low. how can i make updatescreen quickly like miracast/mhl?
At 2015-05-19 23:13:43, "Christian Beier" <don...@fr...> wrote:
>
>What's the problem, actually?
>
>Am Tue, 12 May 2015 14:35:51 +0800 (CST)
>schrieb "BoJing Wang" <198...@16...>:
>
>> 
>> 
>> I am sorry to write email to you , I download your code of libvncserver
>> but i cannot run it, hope you  can help me!!!! thank you.
>> I look forward your reply.
>> 
>> android server log:
>> 130|root@android:/data/local # ./androidvncserver                             
>> Initializing grabber method...
>> --Loading flinger native lib--
>> Loading lib: /data/data/org.onaips.vnc/lib/libdvnc_flinger_sdk17.so
>> AKI1
>> --Initializing gingerbread access method--
>> width:720, height:1280AKII12AKI2
>> Initializing virtual keyboard and touch device...
>> ---Initializing uinput...---
>> Initializing VNC server:
>>     width:  720
>>     height: 1280
>>     bpp:    32
>>     port:   5901
>> Colourmap_rgba=0:8:16:24    lenght=8:8:8:8
>> 12/05/2015 01:08:26 Listening for VNC connections on TCP port 5901
>> 12/05/2015 01:08:26 Listening for HTTP connections on TCP port 5801
>> 12/05/2015 01:08:26   URL http://localhost:5801
>> Starting IPC connection...binded to port 13132
>> Waiting for a connection
>> 12/05/2015 00:55:49 httpd: get '' for 192.168.1.100
>> 12/05/2015 00:55:49 httpd: defaulting to 'index.vnc'
>> 12/05/2015 00:55:49 httpProcessInput: open: No such file or directory
>> 12/05/2015 00:55:49 httpd: get 'favicon.ico' for 192.168.1.100
>> 12/05/2015 00:55:49 httpProcessInput: open: No such file or directory
>> 12/05/2015 00:56:04 Got connection from client 192.168.1.100
>> 12/05/2015 00:55:49 httpd: get 'favicon.ico' for 192.168.1.100
>> 12/05/2015 00:55:49 httpProcessInput: open: No such file or directory
>> 12/05/2015 00:56:04   other clients:
>> 12/05/2015 00:56:05 Normal socket connection
>> 12/05/2015 00:56:05 Client Protocol Version 3.8
>> 12/05/2015 00:56:05 Protocol version sent 3.8, using 3.8
>> 12/05/2015 00:56:05 rfbProcessClientSecurityType: executing handler for type 1
>> 12/05/2015 00:56:05 rfbProcessClientSecurityType: returning securityResult
>> for client rfb version >= 3.8 12/05/2015 00:56:05 Pixel format for client
>> 192.168.1.100: 12/05/2015 00:56:05   32 bpp, depth 24, little endian
>> 12/05/2015 00:56:05   true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
>> 12/05/2015 00:56:05 Using compression level 1 for client 192.168.1.100
>> 12/05/2015 00:56:05 Using image quality level 6 for client 192.168.1.100
>> 12/05/2015 00:56:05 Using JPEG subsampling 0, Q79 for client 192.168.1.100
>> 12/05/2015 00:56:05 Enabling X-style cursor updates for client 192.168.1.100
>> 12/05/2015 00:56:05 Enabling full-color cursor updates for client
>> 192.168.1.100 12/05/2015 00:56:05 Enabling cursor position updates for client
>> 192.168.1.100 12/05/2015 00:56:05 Enabling LastRect protocol extension for
>> client 192.168.1.100 12/05/2015 00:56:05 Using tight encoding for client
>> 192.168.1.100 Segmentation fault
>> 139|root@android:/data/local #
>> 130|root@android:/data/local #
>> 
>> vncviewer log:
>> wangbojing@wangbojing-PC:/mnt/android-source/jb4.2.1$ vncviewer
>> 192.168.1.101:5901 Connected to RFB server, using protocol version 3.8
>> No authentication needed
>> Authentication successful
>> Desktop name "Android"
>> VNC server default format:
>>   32 bits per pixel.
>>   Least significant byte first in each pixel.
>>   True colour: max red 255 green 255 blue 255, shift red 0 green 8 blue 16
>> Warning: Cannot convert string "-*-helvetica-bold-r-*-*-16-*-*-*-*-*-*-*" to
>> type FontStruct Using default colormap which is TrueColor.  Pixel format:
>>   32 bits per pixel.
>>   Least significant byte first in each pixel.
>>   True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
>> vncviewer: VNC server closed connection
>> wangbojing@wangbojing-PC:/mnt/android-source/jb4.2.1$
>> 
>> 
>> 
>> 
>> 
>> 
>> |
>> NameBoJing Wang
>> 198...@16...
>> Organization:
>> Address:
>> Telephone:
>> 手机：15840958489
>> |
>> 
>> 扫描该二维码，可以将电子名片迅速保存到手机 使用帮助
>> 
>> |

Re: [Libvncserver-common] libvncserver

[Christian B. <don...@fr...>]

Ah and if it's a segfault, you should use gdb!

Am Tue, 12 May 2015 14:35:51 +0800 (CST)
schrieb "BoJing Wang" <198...@16...>:

> 
> 
> I am sorry to write email to you , I download your code of libvncserver
> but i cannot run it, hope you  can help me!!!! thank you.
> I look forward your reply.
> 
> android server log:
> 130|root@android:/data/local # ./androidvncserver                             
> Initializing grabber method...
> --Loading flinger native lib--
> Loading lib: /data/data/org.onaips.vnc/lib/libdvnc_flinger_sdk17.so
> AKI1
> --Initializing gingerbread access method--
> width:720, height:1280AKII12AKI2
> Initializing virtual keyboard and touch device...
> ---Initializing uinput...---
> Initializing VNC server:
>     width:  720
>     height: 1280
>     bpp:    32
>     port:   5901
> Colourmap_rgba=0:8:16:24    lenght=8:8:8:8
> 12/05/2015 01:08:26 Listening for VNC connections on TCP port 5901
> 12/05/2015 01:08:26 Listening for HTTP connections on TCP port 5801
> 12/05/2015 01:08:26   URL http://localhost:5801
> Starting IPC connection...binded to port 13132
> Waiting for a connection
> 12/05/2015 00:55:49 httpd: get '' for 192.168.1.100
> 12/05/2015 00:55:49 httpd: defaulting to 'index.vnc'
> 12/05/2015 00:55:49 httpProcessInput: open: No such file or directory
> 12/05/2015 00:55:49 httpd: get 'favicon.ico' for 192.168.1.100
> 12/05/2015 00:55:49 httpProcessInput: open: No such file or directory
> 12/05/2015 00:56:04 Got connection from client 192.168.1.100
> 12/05/2015 00:55:49 httpd: get 'favicon.ico' for 192.168.1.100
> 12/05/2015 00:55:49 httpProcessInput: open: No such file or directory
> 12/05/2015 00:56:04   other clients:
> 12/05/2015 00:56:05 Normal socket connection
> 12/05/2015 00:56:05 Client Protocol Version 3.8
> 12/05/2015 00:56:05 Protocol version sent 3.8, using 3.8
> 12/05/2015 00:56:05 rfbProcessClientSecurityType: executing handler for type 1
> 12/05/2015 00:56:05 rfbProcessClientSecurityType: returning securityResult
> for client rfb version >= 3.8 12/05/2015 00:56:05 Pixel format for client
> 192.168.1.100: 12/05/2015 00:56:05   32 bpp, depth 24, little endian
> 12/05/2015 00:56:05   true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
> 12/05/2015 00:56:05 Using compression level 1 for client 192.168.1.100
> 12/05/2015 00:56:05 Using image quality level 6 for client 192.168.1.100
> 12/05/2015 00:56:05 Using JPEG subsampling 0, Q79 for client 192.168.1.100
> 12/05/2015 00:56:05 Enabling X-style cursor updates for client 192.168.1.100
> 12/05/2015 00:56:05 Enabling full-color cursor updates for client
> 192.168.1.100 12/05/2015 00:56:05 Enabling cursor position updates for client
> 192.168.1.100 12/05/2015 00:56:05 Enabling LastRect protocol extension for
> client 192.168.1.100 12/05/2015 00:56:05 Using tight encoding for client
> 192.168.1.100 Segmentation fault
> 139|root@android:/data/local #
> 130|root@android:/data/local #
> 
> vncviewer log:
> wangbojing@wangbojing-PC:/mnt/android-source/jb4.2.1$ vncviewer
> 192.168.1.101:5901 Connected to RFB server, using protocol version 3.8
> No authentication needed
> Authentication successful
> Desktop name "Android"
> VNC server default format:
>   32 bits per pixel.
>   Least significant byte first in each pixel.
>   True colour: max red 255 green 255 blue 255, shift red 0 green 8 blue 16
> Warning: Cannot convert string "-*-helvetica-bold-r-*-*-16-*-*-*-*-*-*-*" to
> type FontStruct Using default colormap which is TrueColor.  Pixel format:
>   32 bits per pixel.
>   Least significant byte first in each pixel.
>   True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
> vncviewer: VNC server closed connection
> wangbojing@wangbojing-PC:/mnt/android-source/jb4.2.1$
> 
> 
> 
> 
> 
> 
> |
> NameBoJing Wang
> 198...@16...
> Organization:
> Address:
> Telephone:
> 手机：15840958489
> |
> 
> 扫描该二维码，可以将电子名片迅速保存到手机 使用帮助
> 
> |

Re: [Libvncserver-common] libvncserver

[Christian B. <don...@fr...>]

What's the problem, actually?

Am Tue, 12 May 2015 14:35:51 +0800 (CST)
schrieb "BoJing Wang" <198...@16...>:

> 
> 
> I am sorry to write email to you , I download your code of libvncserver
> but i cannot run it, hope you  can help me!!!! thank you.
> I look forward your reply.
> 
> android server log:
> 130|root@android:/data/local # ./androidvncserver                             
> Initializing grabber method...
> --Loading flinger native lib--
> Loading lib: /data/data/org.onaips.vnc/lib/libdvnc_flinger_sdk17.so
> AKI1
> --Initializing gingerbread access method--
> width:720, height:1280AKII12AKI2
> Initializing virtual keyboard and touch device...
> ---Initializing uinput...---
> Initializing VNC server:
>     width:  720
>     height: 1280
>     bpp:    32
>     port:   5901
> Colourmap_rgba=0:8:16:24    lenght=8:8:8:8
> 12/05/2015 01:08:26 Listening for VNC connections on TCP port 5901
> 12/05/2015 01:08:26 Listening for HTTP connections on TCP port 5801
> 12/05/2015 01:08:26   URL http://localhost:5801
> Starting IPC connection...binded to port 13132
> Waiting for a connection
> 12/05/2015 00:55:49 httpd: get '' for 192.168.1.100
> 12/05/2015 00:55:49 httpd: defaulting to 'index.vnc'
> 12/05/2015 00:55:49 httpProcessInput: open: No such file or directory
> 12/05/2015 00:55:49 httpd: get 'favicon.ico' for 192.168.1.100
> 12/05/2015 00:55:49 httpProcessInput: open: No such file or directory
> 12/05/2015 00:56:04 Got connection from client 192.168.1.100
> 12/05/2015 00:55:49 httpd: get 'favicon.ico' for 192.168.1.100
> 12/05/2015 00:55:49 httpProcessInput: open: No such file or directory
> 12/05/2015 00:56:04   other clients:
> 12/05/2015 00:56:05 Normal socket connection
> 12/05/2015 00:56:05 Client Protocol Version 3.8
> 12/05/2015 00:56:05 Protocol version sent 3.8, using 3.8
> 12/05/2015 00:56:05 rfbProcessClientSecurityType: executing handler for type 1
> 12/05/2015 00:56:05 rfbProcessClientSecurityType: returning securityResult
> for client rfb version >= 3.8 12/05/2015 00:56:05 Pixel format for client
> 192.168.1.100: 12/05/2015 00:56:05   32 bpp, depth 24, little endian
> 12/05/2015 00:56:05   true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
> 12/05/2015 00:56:05 Using compression level 1 for client 192.168.1.100
> 12/05/2015 00:56:05 Using image quality level 6 for client 192.168.1.100
> 12/05/2015 00:56:05 Using JPEG subsampling 0, Q79 for client 192.168.1.100
> 12/05/2015 00:56:05 Enabling X-style cursor updates for client 192.168.1.100
> 12/05/2015 00:56:05 Enabling full-color cursor updates for client
> 192.168.1.100 12/05/2015 00:56:05 Enabling cursor position updates for client
> 192.168.1.100 12/05/2015 00:56:05 Enabling LastRect protocol extension for
> client 192.168.1.100 12/05/2015 00:56:05 Using tight encoding for client
> 192.168.1.100 Segmentation fault
> 139|root@android:/data/local #
> 130|root@android:/data/local #
> 
> vncviewer log:
> wangbojing@wangbojing-PC:/mnt/android-source/jb4.2.1$ vncviewer
> 192.168.1.101:5901 Connected to RFB server, using protocol version 3.8
> No authentication needed
> Authentication successful
> Desktop name "Android"
> VNC server default format:
>   32 bits per pixel.
>   Least significant byte first in each pixel.
>   True colour: max red 255 green 255 blue 255, shift red 0 green 8 blue 16
> Warning: Cannot convert string "-*-helvetica-bold-r-*-*-16-*-*-*-*-*-*-*" to
> type FontStruct Using default colormap which is TrueColor.  Pixel format:
>   32 bits per pixel.
>   Least significant byte first in each pixel.
>   True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
> vncviewer: VNC server closed connection
> wangbojing@wangbojing-PC:/mnt/android-source/jb4.2.1$
> 
> 
> 
> 
> 
> 
> |
> NameBoJing Wang
> 198...@16...
> Organization:
> Address:
> Telephone:
> 手机：15840958489
> |
> 
> 扫描该二维码，可以将电子名片迅速保存到手机 使用帮助
> 
> |

[Libvncserver-common] libvncserver

[BoJing W. <198...@16...>]

I am sorry to write email to you , I download your code of libvncserver
but i cannot run it, hope you  can help me!!!! thank you.
I look forward your reply.

android server log:
130|root@android:/data/local # ./androidvncserver                             
Initializing grabber method...
--Loading flinger native lib--
Loading lib: /data/data/org.onaips.vnc/lib/libdvnc_flinger_sdk17.so
AKI1
--Initializing gingerbread access method--
width:720, height:1280AKII12AKI2
Initializing virtual keyboard and touch device...
---Initializing uinput...---
Initializing VNC server:
    width:  720
    height: 1280
    bpp:    32
    port:   5901
Colourmap_rgba=0:8:16:24    lenght=8:8:8:8
12/05/2015 01:08:26 Listening for VNC connections on TCP port 5901
12/05/2015 01:08:26 Listening for HTTP connections on TCP port 5801
12/05/2015 01:08:26   URL http://localhost:5801
Starting IPC connection...binded to port 13132
Waiting for a connection
12/05/2015 00:55:49 httpd: get '' for 192.168.1.100
12/05/2015 00:55:49 httpd: defaulting to 'index.vnc'
12/05/2015 00:55:49 httpProcessInput: open: No such file or directory
12/05/2015 00:55:49 httpd: get 'favicon.ico' for 192.168.1.100
12/05/2015 00:55:49 httpProcessInput: open: No such file or directory
12/05/2015 00:56:04 Got connection from client 192.168.1.100
12/05/2015 00:55:49 httpd: get 'favicon.ico' for 192.168.1.100
12/05/2015 00:55:49 httpProcessInput: open: No such file or directory
12/05/2015 00:56:04   other clients:
12/05/2015 00:56:05 Normal socket connection
12/05/2015 00:56:05 Client Protocol Version 3.8
12/05/2015 00:56:05 Protocol version sent 3.8, using 3.8
12/05/2015 00:56:05 rfbProcessClientSecurityType: executing handler for type 1
12/05/2015 00:56:05 rfbProcessClientSecurityType: returning securityResult for client rfb version >= 3.8
12/05/2015 00:56:05 Pixel format for client 192.168.1.100:
12/05/2015 00:56:05   32 bpp, depth 24, little endian
12/05/2015 00:56:05   true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
12/05/2015 00:56:05 Using compression level 1 for client 192.168.1.100
12/05/2015 00:56:05 Using image quality level 6 for client 192.168.1.100
12/05/2015 00:56:05 Using JPEG subsampling 0, Q79 for client 192.168.1.100
12/05/2015 00:56:05 Enabling X-style cursor updates for client 192.168.1.100
12/05/2015 00:56:05 Enabling full-color cursor updates for client 192.168.1.100
12/05/2015 00:56:05 Enabling cursor position updates for client 192.168.1.100
12/05/2015 00:56:05 Enabling LastRect protocol extension for client 192.168.1.100
12/05/2015 00:56:05 Using tight encoding for client 192.168.1.100
Segmentation fault
139|root@android:/data/local #
130|root@android:/data/local #

vncviewer log:
wangbojing@wangbojing-PC:/mnt/android-source/jb4.2.1$ vncviewer 192.168.1.101:5901
Connected to RFB server, using protocol version 3.8
No authentication needed
Authentication successful
Desktop name "Android"
VNC server default format:
  32 bits per pixel.
  Least significant byte first in each pixel.
  True colour: max red 255 green 255 blue 255, shift red 0 green 8 blue 16
Warning: Cannot convert string "-*-helvetica-bold-r-*-*-16-*-*-*-*-*-*-*" to type FontStruct
Using default colormap which is TrueColor.  Pixel format:
  32 bits per pixel.
  Least significant byte first in each pixel.
  True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
vncviewer: VNC server closed connection
wangbojing@wangbojing-PC:/mnt/android-source/jb4.2.1$






|
NameBoJing Wang
198...@16...
Organization:
Address:
Telephone:
手机：15840958489
|

扫描该二维码，可以将电子名片迅速保存到手机 使用帮助

|

Re: [Libvncserver-common] Getting cursor displayed using libvnc client

[Christian B. <don...@fr...>]

Am Fri, 8 May 2015 13:10:42 +0530
schrieb Safeer C <saf...@gm...>:

> Hi,
> 
> I was using libvnc clent 0.9.9 for capturing the local network device
> screens, I am not getting the cursor displayed in the image.But I am
> able to send mouse events.
> 
> I am using osgWidget::VncImage in visual studio 2008
> 
> I have tried setting the following parameter, but did not help
> 
> _client->appData.useRemoteCursor = true;
> _client->GotCursorShape = 0;
> _client->HandleCursorPos = position_func;
> 
> 
> Any help please.
> 
> Thanks
> Safeer
> 
> 
> 

Are you sure that the server actually sends the cursor image?

[Libvncserver-common] Getting cursor displayed using libvnc client

[Safeer C <saf...@gm...>]

Hi,

I was using libvnc clent 0.9.9 for capturing the local network device
screens, I am not getting the cursor displayed in the image.But I am able
to send mouse events.

I am using osgWidget::VncImage in visual studio 2008

I have tried setting the following parameter, but did not help

_client->appData.useRemoteCursor = true;
_client->GotCursorShape = 0;
_client->HandleCursorPos = position_func;


Any help please.

Thanks
Safeer



-- 
--------------------------------------
*SAFEER CHONENGAL*

*Engineer Graphics*

*Viz Experts India Pvt Ltd*
+91 8308803801
http://safeer.x10host.com
---------------------------------------

Re: [Libvncserver-common] Performance issue / deferred update question

[Paul M. <pau...@su...>]

Hi DRC,

Thanks for the extensive comments. You do mention the defer update 
timer, but I feel you mostly describe client-side issues and options. 
However, the problem I'm trying to overcome seems server-related, 
specifically libvncserver.

I basically have a 3D test application that runs fine with 
TurboVNC(s)+VirtualGL+TigerVNC(c). But when I try to VNC-ify that 
application by using offscreen OpenGL rendering, linking in libvncserver 
and providing framebuffer updates based on mouse/kb input then updates 
sent from the server behave erratically in case the application frame 
update rate become slower (say 100 fps or slower). I'm already limiting 
the frame buffer modified marking rate, btw.

The behaviour just doesn't make much sense to me and is also shown by 
the simple rectangles example I sent earlier (to rule out any drawing 
issues with the 3D app). What I can't get my head around is why a 
relatively LOW rate of marking framebuffer updates in libvncserver (say 
with 50fps) would cause it to buffer those updates and send them out in 
delayed chunks of multiple updates, causing the crappy update rate in 
the client? And when slowing down the drawing rate to something as low 
as 5 fps on the server and using a DUT of 1ms ("./rectangles 1 200") the 
updates on the client side come 5-10 seconds after the mouse interaction 
and combine several frame updates in one. libvncserver should easily be 
able to keep up with such a low frame rate.

As far as I can tell the events in the rectangles example ARE continuing 
in the right pace, i.e. I see a draw + framebuffer modified mark roughly 
every 200ms:

[1431010891.676082] MARKING framebuffer modified
[1431010891.676130] fill 201.494 ms, mark 0.048 ms
[1431010891.676163] Drawing rectangle
[1431010891.877670] MARKING framebuffer modified
[1431010891.877717] fill 201.507 ms, mark 0.047 ms
[1431010891.877749] Drawing rectangle
[1431010892.079237] MARKING framebuffer modified
[1431010892.079284] fill 201.488 ms, mark 0.047 ms
[1431010892.079317] Drawing rectangle
[1431010892.280822] MARKING framebuffer modified
[1431010892.280864] fill 201.505 ms, mark 0.042 ms
[1431010892.280897] Drawing rectangle
[1431010892.482376] MARKING framebuffer modified
[1431010892.482423] fill 201.479 ms, mark 0.047 ms
[1431010892.482457] Drawing rectangle
[1431010892.684001] MARKING framebuffer modified
[1431010892.684047] fill 201.544 ms, mark 0.046 ms
[1431010892.684081] Drawing rectangle
[1431010892.885571] MARKING framebuffer modified
[1431010892.885617] fill 201.490 ms, mark 0.046 ms
[1431010892.885650] Drawing rectangle
[1431010893.087130] MARKING framebuffer modified
[1431010893.087176] fill 201.480 ms, mark 0.046 ms
[1431010893.087221] Drawing rectangle
[1431010893.288705] MARKING framebuffer modified
[1431010893.288748] fill 201.484 ms, mark 0.043 ms
[1431010893.347916] Drawing rectangle
[1431010893.549469] MARKING framebuffer modified
[1431010893.549531] fill 201.553 ms, mark 0.062 ms
[1431010893.549608] Drawing rectangle
[1431010893.751100] MARKING framebuffer modified

But the updates either don't get sent immediately by libvncserver, or 
there is some issue with the combination of libserver and client (both 
TigerVNC and TurboVNC) causing them to get on the screen severy delayed 
and combined.

Regards,
Paul

On 06-05-15 17:06, DRC wrote:
> I'm not sure whether any of the information that follows is germane to
> the issue you're having, but I thought I would share it all the same,
> since the description of the issue rang a few bells in my head.
> Minimally, this information may provide some insight into the
> interaction between the deferred update timer and the TurboVNC encoder
> (which libvncserver now uses, as of version 0.9.9.)
>
> Section 5.2 of this report:
>
> http://www.virtualgl.org/pmwiki/uploads/About/vglperf21.pdf
>
> goes into some detail about the history of the deferred update timer
> within TurboVNC and the issues it posed when the TightVNC codec and
> protocol were first accelerated to make TurboVNC.  I'll attempt to
> summarize here:
>
> -- Initially, TightVNC 1.3.x used a deferred update timer value of 40
> ms, and the viewer waited until the current framebuffer update (FBU) was
> drawn before sending a new framebuffer update request (FBUR) to the
> server.  As you can imagine, this is reeeeally slow on low-latency
> networks, but because the TightVNC codec was already really slow, the
> network latency wasn't really the limiting factor.  But once the codec
> became an order of magnitude faster in TurboVNC, now the network latency
> was a big issue.
>
> -- In TurboVNC 0.3.2, I attempted to improve the performance on
> low-latency networks by pipelining the viewer a bit.  Now it would send
> a FBUR back to the server before decoding and drawing the current FBU.
> This worked great on high-latency networks, but it created a new
> performance issue on low-latency networks.  For reasons that are more
> properly explained in the report above, whenever the new FBUR was
> received from the server before the application had drawn a new frame,
> this caused the new frame to be deferred by the VNC server.  Otherwise,
> if the application had drawn a new frame before the new FBUR arrived,
> then the FBU was sent immediately.  Thus, pipelining the viewer caused
> the new FBUR to arrive at the server "too quickly" when the network
> latency was low, and this caused every frame the application drew to be
> deferred.  With a DUT value of 40 ms, this slowed performance to a
> crawl.  It was essentially the same as introducing 40 ms of network
> latency, and the overall update rate dropped to 1 / (2 * 40 ms) = about
> 12/sec.  On modern PC equipment available at the time, TurboVNC was
> normally capable of streaming 1280 x 1024 x 25 fps on a 100 Mbit
> network, so this represented a 50% performance regression on such networks.
>
> -- In TurboVNC 0.3.3, I introduced a switch that allowed the user to
> turn on or off pipelining in the viewer depending on whether they were
> on a low-latency or high-latency network, but this was a total hack.
> Ultimately, in TurboVNC 0.4, I discovered after a great deal of testing
> that using a 1 ms deferred update timer value along with the pipelining
> feature in the viewer provided the best possible performance on both
> high-latency and low-latency networks.
>
>
> So I think the basic takeaway is that, in order to achieve the best
> performance possible for high-update-rate applications without using the
> RFB flow control extensions, you have to send a new FBUR in the client
> before processing the current FBU, and you have to set the server's DUT
> to a very low value (my own testing with VirtualGL indicated that 1 ms
> was the best value, but your mileage may vary.)  Even with this, though,
> you're still going to be latency-bound (limited to [1 / latency]
> updates/sec.)  This means that, if the network bandwidth and encoding
> settings would normally be able to accommodate a higher update rate than
> [1 / latency], that higher update rate won't ever be achieved.  That is
> the raison d'etre of the RFB flow control extensions.
>
>
> On 5/6/15 3:06 AM, Paul Melis wrote:
>> Hmmm, is this related to libvncserver not supporting the
>> ContinuousUpdates and Fence RFB extensions (see e.g. [1]), which most
>> other VNC servers these days do support? I mean, using an application
>> with high update rate in a regular VNC session (e.g. TurboVNC) has never
>> been an issue for me so far, but that might be because the update rate
>> from server to client in that case is decoupled from the client request
>> rate and limited on the server side by the extensions, while the actual
>> framebuffer update rate on the server is much higher.
>>
>> Paul
>>
>> [1] http://sourceforge.net/p/libvncserver/mailman/message/31374353/
>>
>> On 04-05-15 17:51, Paul Melis wrote:
>>> Hi all,
>>>
>>> I'm trying to get my head around a performance issue with libvncserver.
>>> See the attached example, which reproduces the problem (the VNC client
>>> I'm using is TigerVNC 1.4.3 on an Arch Linux 64-bit system, with
>>> libvncserver 0.9.10). The example simply draws colored (and noisy, to
>>> make compression harder) rectangles whenever the mouse is moved if a
>>> button is being pressed, in order to judge the framebuffer update
>>> performance.
>>>
>>> The example has two arguments: the deferUpdateTime value to use and a
>>> sleep value to use when drawing (both in ms). The latter value can be
>>> increased to simulate a draw routine that takes some time to complete
>>> (which is typical for my actual application).
>>>
>>> When I use the default deferUpdateTime value of 5 ms and use 0 for the
>>> sleep time the performance in the client is great, draw updates come
>>> almost instantly, even when using very fast mouse movements (and thus
>>> many rectangles get drawn).
>>>
>>> When I increase the sleep value to 10 ms, so each rectangle takes a bit
>>> of time to draw (but still can do around 100 fps), and use fast mouse
>>> movements the updates are no longer smooth and whole bunches of
>>> rectangles get drawn intermittently. This suggests that only every few
>>> frame buffer updates an update is sent to the client. I first thought
>>> that this had to do with the deferUpdateTime, but setting it to 0
>>> doesn't really help.
>>>
>>> Maybe the choppy behaviour is an interaction between the mouse events
>>> getting sent at a high rate when using fast movements versus the slow fb
>>> update response to each event. When using slower mouse movements
>>> rectangles get drawn mostly one at a time, suggesting the frame buffer
>>> updates can be keep up. If this is the case, is there a general way to
>>> handle this kind of workload (other than rate limiting the
>>> rfbMarkRectAsModified() calls)?
>>>
>>> Regards,
>>> Paul
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> One dashboard for servers and applications across Physical-Virtual-Cloud
>>> Widest out-of-the-box monitoring support with 50+ applications
>>> Performance metrics, stats and reports that give you Actionable Insights
>>> Deep dive visibility with transaction tracing using APM Insight.
>>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>>
>>>
>>>
>>> _______________________________________________
>>> LibVNCServer-common mailing list
>>> Lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/libvncserver-common
>>>
>>
>>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> LibVNCServer-common mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libvncserver-common
>


-- 

Paul Melis
| Groepsleider & Adviseur Visualisatie | SURFsara |
| Science Park 140 | 1098 XG Amsterdam |
| T 020 800 1312 | pau...@su... | www.surfsara.nl |

Re: [Libvncserver-common] Performance issue / deferred update question

[DRC <dco...@us...>]

I'm not sure whether any of the information that follows is germane to 
the issue you're having, but I thought I would share it all the same, 
since the description of the issue rang a few bells in my head. 
Minimally, this information may provide some insight into the 
interaction between the deferred update timer and the TurboVNC encoder 
(which libvncserver now uses, as of version 0.9.9.)

Section 5.2 of this report:

http://www.virtualgl.org/pmwiki/uploads/About/vglperf21.pdf

goes into some detail about the history of the deferred update timer 
within TurboVNC and the issues it posed when the TightVNC codec and 
protocol were first accelerated to make TurboVNC.  I'll attempt to 
summarize here:

-- Initially, TightVNC 1.3.x used a deferred update timer value of 40 
ms, and the viewer waited until the current framebuffer update (FBU) was 
drawn before sending a new framebuffer update request (FBUR) to the 
server.  As you can imagine, this is reeeeally slow on low-latency 
networks, but because the TightVNC codec was already really slow, the 
network latency wasn't really the limiting factor.  But once the codec 
became an order of magnitude faster in TurboVNC, now the network latency 
was a big issue.

-- In TurboVNC 0.3.2, I attempted to improve the performance on 
low-latency networks by pipelining the viewer a bit.  Now it would send 
a FBUR back to the server before decoding and drawing the current FBU. 
This worked great on high-latency networks, but it created a new 
performance issue on low-latency networks.  For reasons that are more 
properly explained in the report above, whenever the new FBUR was 
received from the server before the application had drawn a new frame, 
this caused the new frame to be deferred by the VNC server.  Otherwise, 
if the application had drawn a new frame before the new FBUR arrived, 
then the FBU was sent immediately.  Thus, pipelining the viewer caused 
the new FBUR to arrive at the server "too quickly" when the network 
latency was low, and this caused every frame the application drew to be 
deferred.  With a DUT value of 40 ms, this slowed performance to a 
crawl.  It was essentially the same as introducing 40 ms of network 
latency, and the overall update rate dropped to 1 / (2 * 40 ms) = about 
12/sec.  On modern PC equipment available at the time, TurboVNC was 
normally capable of streaming 1280 x 1024 x 25 fps on a 100 Mbit 
network, so this represented a 50% performance regression on such networks.

-- In TurboVNC 0.3.3, I introduced a switch that allowed the user to 
turn on or off pipelining in the viewer depending on whether they were 
on a low-latency or high-latency network, but this was a total hack. 
Ultimately, in TurboVNC 0.4, I discovered after a great deal of testing 
that using a 1 ms deferred update timer value along with the pipelining 
feature in the viewer provided the best possible performance on both 
high-latency and low-latency networks.


So I think the basic takeaway is that, in order to achieve the best 
performance possible for high-update-rate applications without using the 
RFB flow control extensions, you have to send a new FBUR in the client 
before processing the current FBU, and you have to set the server's DUT 
to a very low value (my own testing with VirtualGL indicated that 1 ms 
was the best value, but your mileage may vary.)  Even with this, though, 
you're still going to be latency-bound (limited to [1 / latency] 
updates/sec.)  This means that, if the network bandwidth and encoding 
settings would normally be able to accommodate a higher update rate than 
[1 / latency], that higher update rate won't ever be achieved.  That is 
the raison d'etre of the RFB flow control extensions.


On 5/6/15 3:06 AM, Paul Melis wrote:
> Hmmm, is this related to libvncserver not supporting the
> ContinuousUpdates and Fence RFB extensions (see e.g. [1]), which most
> other VNC servers these days do support? I mean, using an application
> with high update rate in a regular VNC session (e.g. TurboVNC) has never
> been an issue for me so far, but that might be because the update rate
> from server to client in that case is decoupled from the client request
> rate and limited on the server side by the extensions, while the actual
> framebuffer update rate on the server is much higher.
>
> Paul
>
> [1] http://sourceforge.net/p/libvncserver/mailman/message/31374353/
>
> On 04-05-15 17:51, Paul Melis wrote:
>> Hi all,
>>
>> I'm trying to get my head around a performance issue with libvncserver.
>> See the attached example, which reproduces the problem (the VNC client
>> I'm using is TigerVNC 1.4.3 on an Arch Linux 64-bit system, with
>> libvncserver 0.9.10). The example simply draws colored (and noisy, to
>> make compression harder) rectangles whenever the mouse is moved if a
>> button is being pressed, in order to judge the framebuffer update
>> performance.
>>
>> The example has two arguments: the deferUpdateTime value to use and a
>> sleep value to use when drawing (both in ms). The latter value can be
>> increased to simulate a draw routine that takes some time to complete
>> (which is typical for my actual application).
>>
>> When I use the default deferUpdateTime value of 5 ms and use 0 for the
>> sleep time the performance in the client is great, draw updates come
>> almost instantly, even when using very fast mouse movements (and thus
>> many rectangles get drawn).
>>
>> When I increase the sleep value to 10 ms, so each rectangle takes a bit
>> of time to draw (but still can do around 100 fps), and use fast mouse
>> movements the updates are no longer smooth and whole bunches of
>> rectangles get drawn intermittently. This suggests that only every few
>> frame buffer updates an update is sent to the client. I first thought
>> that this had to do with the deferUpdateTime, but setting it to 0
>> doesn't really help.
>>
>> Maybe the choppy behaviour is an interaction between the mouse events
>> getting sent at a high rate when using fast movements versus the slow fb
>> update response to each event. When using slower mouse movements
>> rectangles get drawn mostly one at a time, suggesting the frame buffer
>> updates can be keep up. If this is the case, is there a general way to
>> handle this kind of workload (other than rate limiting the
>> rfbMarkRectAsModified() calls)?
>>
>> Regards,
>> Paul
>>
>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>
>>
>>
>> _______________________________________________
>> LibVNCServer-common mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libvncserver-common
>>
>
>

Re: [Libvncserver-common] Performance issue / deferred update question

[Paul M. <pau...@su...>]

Hmmm, is this related to libvncserver not supporting the 
ContinuousUpdates and Fence RFB extensions (see e.g. [1]), which most 
other VNC servers these days do support? I mean, using an application 
with high update rate in a regular VNC session (e.g. TurboVNC) has never 
been an issue for me so far, but that might be because the update rate 
from server to client in that case is decoupled from the client request 
rate and limited on the server side by the extensions, while the actual 
framebuffer update rate on the server is much higher.

Paul

[1] http://sourceforge.net/p/libvncserver/mailman/message/31374353/

On 04-05-15 17:51, Paul Melis wrote:
> Hi all,
>
> I'm trying to get my head around a performance issue with libvncserver.
> See the attached example, which reproduces the problem (the VNC client
> I'm using is TigerVNC 1.4.3 on an Arch Linux 64-bit system, with
> libvncserver 0.9.10). The example simply draws colored (and noisy, to
> make compression harder) rectangles whenever the mouse is moved if a
> button is being pressed, in order to judge the framebuffer update
> performance.
>
> The example has two arguments: the deferUpdateTime value to use and a
> sleep value to use when drawing (both in ms). The latter value can be
> increased to simulate a draw routine that takes some time to complete
> (which is typical for my actual application).
>
> When I use the default deferUpdateTime value of 5 ms and use 0 for the
> sleep time the performance in the client is great, draw updates come
> almost instantly, even when using very fast mouse movements (and thus
> many rectangles get drawn).
>
> When I increase the sleep value to 10 ms, so each rectangle takes a bit
> of time to draw (but still can do around 100 fps), and use fast mouse
> movements the updates are no longer smooth and whole bunches of
> rectangles get drawn intermittently. This suggests that only every few
> frame buffer updates an update is sent to the client. I first thought
> that this had to do with the deferUpdateTime, but setting it to 0
> doesn't really help.
>
> Maybe the choppy behaviour is an interaction between the mouse events
> getting sent at a high rate when using fast movements versus the slow fb
> update response to each event. When using slower mouse movements
> rectangles get drawn mostly one at a time, suggesting the frame buffer
> updates can be keep up. If this is the case, is there a general way to
> handle this kind of workload (other than rate limiting the
> rfbMarkRectAsModified() calls)?
>
> Regards,
> Paul
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
>
> _______________________________________________
> LibVNCServer-common mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libvncserver-common
>


-- 

Paul Melis
| Groepsleider & Adviseur Visualisatie | SURFsara |
| Science Park 140 | 1098 XG Amsterdam |
| T 020 800 1312 | pau...@su... | www.surfsara.nl |

[Libvncserver-common] Performance issue / deferred update question

[Paul M. <pau...@su...>]

Hi all,

I'm trying to get my head around a performance issue with libvncserver.
See the attached example, which reproduces the problem (the VNC client 
I'm using is TigerVNC 1.4.3 on an Arch Linux 64-bit system, with 
libvncserver 0.9.10). The example simply draws colored (and noisy, to 
make compression harder) rectangles whenever the mouse is moved if a 
button is being pressed, in order to judge the framebuffer update 
performance.

The example has two arguments: the deferUpdateTime value to use and a 
sleep value to use when drawing (both in ms). The latter value can be 
increased to simulate a draw routine that takes some time to complete 
(which is typical for my actual application).

When I use the default deferUpdateTime value of 5 ms and use 0 for the 
sleep time the performance in the client is great, draw updates come 
almost instantly, even when using very fast mouse movements (and thus 
many rectangles get drawn).

When I increase the sleep value to 10 ms, so each rectangle takes a bit 
of time to draw (but still can do around 100 fps), and use fast mouse 
movements the updates are no longer smooth and whole bunches of 
rectangles get drawn intermittently. This suggests that only every few 
frame buffer updates an update is sent to the client. I first thought 
that this had to do with the deferUpdateTime, but setting it to 0 
doesn't really help.

Maybe the choppy behaviour is an interaction between the mouse events 
getting sent at a high rate when using fast movements versus the slow fb 
update response to each event. When using slower mouse movements 
rectangles get drawn mostly one at a time, suggesting the frame buffer 
updates can be keep up. If this is the case, is there a general way to 
handle this kind of workload (other than rate limiting the 
rfbMarkRectAsModified() calls)?

Regards,
Paul

-- 

Paul Melis
| Groepsleider & Adviseur Visualisatie | SURFsara |
| Science Park 140 | 1098 XG Amsterdam |
| T 020 800 1312 | pau...@su... | www.surfsara.nl |

[Libvncserver-common] Fwd: LibVNCServer and LibVNCClient windows binaries

[harun k. <har...@gm...>]

Dear All,

I need Libvncserver and Libvncclient windows binaries. I have tried more
times to compile project on win32 mingw but I can not compile successfuly.
Could you please share with me compiled binaries.

Thank you for your helps,

-- 

Best Regards