directvnc-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Directvnc-user] too good to be true?


From: Rob McGee
Subject: [Directvnc-user] too good to be true?
Date: Sat, 2 Nov 2002 22:40:10 -0600
User-agent: Mutt/1.3.27i

I was very excited when I found this project. Wow, just what I've
wanted! This was 3 days ago. I got DFB 0.9.14 and DirectVNC 0.7. DFB
compiled fine. BTW this is a Slackware 8.0 system with some 8.1 packages
(some of which were used by DFB.) A Matrox something-or-other 4MB PCI
video card running the matroxfb driver, kernel 2.4.17.

DVNC's configure said I needed pkg-config, so I got 0.14.0. This wasn't
mentioned in either README. I compiled that and noted with alarm that it
includes glib-1.2.8. I have 1.2.10 already installed! So rather than let
in install its glib, I copied the pkg-config binary (stripped) to the
usual /usr/local/bin.

DVNC was happy enough. As best I could tell from "man pkg-config", it
isn't something needed at runtime, right?

So on to runtime ... drooling in anticipation ... wait, wipe off the
keyboard ... directvnc hal:1 ... asked for password ... authenticated
...

That was it. That was all she wrote. If I wasn't such a GNU/Linux whiz
I would have thought she was doing a Windows-style crash. No, it wasn't
the system, it was only the framebuffer display. Remotely I could paint
things on the framebuffer (cat file.png > /dev/fb0), but I couldn't get
a working display back.

Goodbye uptime, hello 3-finger-salute. :)

I tried again after rebooting, thinking that perhaps I needed to adjust
the VNC server's parameters, specifically the color depth. I set it to
match the framebuffer:

address@hidden:~# fbset -i

mode "1024x768-70"
    # D: 74.996 MHz, H: 56.473 kHz, V: 70.066 Hz
    geometry 1024 768 1024 768 16
    timings 13334 144 24 29 3 136 6
    accel true
    rgba 5/11,6/5,5/0,0/0
endmode

Frame buffer device information:
    Name        : MATROX
    Address     : 0xff000000
    Size        : 4194304
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 8
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 2048
    MMIO Address: 0xffefc000
    MMIO Size   : 16384
    Accelerator : Matrox MGA2064W (Millennium)

I started vncserver (this is TightVNC 1.2.3, BTW) like this:

address@hidden:~$ vncserver -depth 16 :1

(the default geometry is 1024x768)

Then the retry:

address@hidden:~$ directvnc hal:1 -b 16
Password:
authenticated[1]

Here's the hal:1.log of the retry:

31/10/02 11:35:09 Xvnc version 3.3.3r2+tight1.2.3
31/10/02 11:35:09 Copyright (C) AT&T Laboratories Cambridge.
31/10/02 11:35:09 All Rights Reserved.
31/10/02 11:35:09 See http://www.uk.research.att.com/vnc for information on VNC
31/10/02 11:35:09 Desktop name 'X' (hal:1)
31/10/02 11:35:09 Protocol version supported 3.3
31/10/02 11:35:09 Listening for VNC connections on TCP port 5901
31/10/02 11:35:09 Listening for HTTP connections on TCP port 5801
31/10/02 11:35:09   URL http://hal:5801

31/10/02 11:36:47 Got connection from client 10.1.1.10
31/10/02 11:36:47 Protocol version 3.3
31/10/02 11:36:51 Pixel format for client 10.1.1.10:
31/10/02 11:36:51   16 bpp, depth 16, little endian
31/10/02 11:36:51   true colour: max r 31 g 63 b 31, shift r 11 g 5 b 0
31/10/02 11:36:51   no translation needed
31/10/02 11:36:51 Using tight encoding for client 10.0.0.166
31/10/02 11:36:51 Enabling full-color cursor updates for client 10.0.0.166
31/10/02 11:36:51 Client 10.1.1.10 gone
31/10/02 11:36:51 Statistics:
31/10/02 11:36:51   framebuffer updates 0, rectangles 0, bytes 0
XIO:  fatal IO error 104 (Connection reset by peer) on X server ":1.0"
      after 9940 requests (1473 known processed) with 0 events remaining.

IIRC I quit this with ctrl-alt-del (reboot), but that was substantially
after 11:36:51.

I'd like to get this working, although my enthusiasm was dampened a bit
by reading the list archive ... my dream of having a different VNC on
every tty isn't going to happen, at least not yet.

Any ideas on what I should try next? Maybe go back to an older version
of DFB? Should I be on the DFB list also or instead?

Till, let me know if more details are needed. Thanks for working on
this; it sure is a great idea if it works.

    Rob - /dev/rob0


[1] I can't remember the exact message there.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]