Getting black screen when connected with x11vnc





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







2















I'm trying to run an x11vnc server so that someone can connect remotely to my computer, but I'm having trouble getting it to work. I'm using Ubuntu 14.04 and testing the VNC server by using Vinagre to connect on localhost. I get a login prompt and it accepts the password, but then I just get a black screen. This doesn't seem to be an uncommon problem but I've tried tons of solutions I've found through Google and none of them have worked for me. The x11vnc log doesn't give any indication of errors so I don't know where to begin to figure out what is wrong.



My x11vnc command:



x11vnc -xkb -noxrecord -noxfixes -noxdamage -display :1 -auth /var/run/lightdm/root/:1 -usepw -forever -o /var/log/x11vnc.log


The x11vnc log:



11/08/2015 15:14:43 Got connection from client 127.0.0.1
11/08/2015 15:14:43 other clients:
11/08/2015 15:14:43 Normal socket connection
11/08/2015 15:14:43 Disabled X server key autorepeat.
11/08/2015 15:14:43 to force back on run: 'xset r on' (3 times)
11/08/2015 15:14:43 incr accepted_client=5 for 127.0.0.1:48227 sock=7
11/08/2015 15:14:43 Client Protocol Version 3.8
11/08/2015 15:14:43 Protocol version sent 3.8, using 3.8
11/08/2015 15:14:43 rfbProcessClientSecurityType: executing handler for type 2
11/08/2015 15:14:46 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFE)
11/08/2015 15:14:46 Enabling NewFBSize protocol extension for client 127.0.0.1
11/08/2015 15:14:46 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x574D5669)
11/08/2015 15:14:46 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFD)
11/08/2015 15:14:46 Enabling full-color cursor updates for client 127.0.0.1
11/08/2015 15:14:46 Enabling X-style cursor updates for client 127.0.0.1
11/08/2015 15:14:46 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFF)
11/08/2015 15:14:46 Using tight encoding for client 127.0.0.1
11/08/2015 15:14:48 client useCopyRect: 127.0.0.1 -1
11/08/2015 15:14:48 client_set_net: 127.0.0.1 0.0001


My current ~/.vnc/xstartup (I've tried a bunch of variations):



#!/bin/sh

export XKL_XMODMAP_DISABLE=1
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &

gnome-panel &
gnome-settings-daemon &
metacity &
nautilus &
gnome-terminal &









share|improve this question














bumped to the homepage by Community 5 hours ago


This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.






















    2















    I'm trying to run an x11vnc server so that someone can connect remotely to my computer, but I'm having trouble getting it to work. I'm using Ubuntu 14.04 and testing the VNC server by using Vinagre to connect on localhost. I get a login prompt and it accepts the password, but then I just get a black screen. This doesn't seem to be an uncommon problem but I've tried tons of solutions I've found through Google and none of them have worked for me. The x11vnc log doesn't give any indication of errors so I don't know where to begin to figure out what is wrong.



    My x11vnc command:



    x11vnc -xkb -noxrecord -noxfixes -noxdamage -display :1 -auth /var/run/lightdm/root/:1 -usepw -forever -o /var/log/x11vnc.log


    The x11vnc log:



    11/08/2015 15:14:43 Got connection from client 127.0.0.1
    11/08/2015 15:14:43 other clients:
    11/08/2015 15:14:43 Normal socket connection
    11/08/2015 15:14:43 Disabled X server key autorepeat.
    11/08/2015 15:14:43 to force back on run: 'xset r on' (3 times)
    11/08/2015 15:14:43 incr accepted_client=5 for 127.0.0.1:48227 sock=7
    11/08/2015 15:14:43 Client Protocol Version 3.8
    11/08/2015 15:14:43 Protocol version sent 3.8, using 3.8
    11/08/2015 15:14:43 rfbProcessClientSecurityType: executing handler for type 2
    11/08/2015 15:14:46 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFE)
    11/08/2015 15:14:46 Enabling NewFBSize protocol extension for client 127.0.0.1
    11/08/2015 15:14:46 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x574D5669)
    11/08/2015 15:14:46 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFD)
    11/08/2015 15:14:46 Enabling full-color cursor updates for client 127.0.0.1
    11/08/2015 15:14:46 Enabling X-style cursor updates for client 127.0.0.1
    11/08/2015 15:14:46 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFF)
    11/08/2015 15:14:46 Using tight encoding for client 127.0.0.1
    11/08/2015 15:14:48 client useCopyRect: 127.0.0.1 -1
    11/08/2015 15:14:48 client_set_net: 127.0.0.1 0.0001


    My current ~/.vnc/xstartup (I've tried a bunch of variations):



    #!/bin/sh

    export XKL_XMODMAP_DISABLE=1
    unset SESSION_MANAGER
    unset DBUS_SESSION_BUS_ADDRESS

    [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
    [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
    xsetroot -solid grey
    vncconfig -iconic &

    gnome-panel &
    gnome-settings-daemon &
    metacity &
    nautilus &
    gnome-terminal &









    share|improve this question














    bumped to the homepage by Community 5 hours ago


    This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.


















      2












      2








      2


      1






      I'm trying to run an x11vnc server so that someone can connect remotely to my computer, but I'm having trouble getting it to work. I'm using Ubuntu 14.04 and testing the VNC server by using Vinagre to connect on localhost. I get a login prompt and it accepts the password, but then I just get a black screen. This doesn't seem to be an uncommon problem but I've tried tons of solutions I've found through Google and none of them have worked for me. The x11vnc log doesn't give any indication of errors so I don't know where to begin to figure out what is wrong.



      My x11vnc command:



      x11vnc -xkb -noxrecord -noxfixes -noxdamage -display :1 -auth /var/run/lightdm/root/:1 -usepw -forever -o /var/log/x11vnc.log


      The x11vnc log:



      11/08/2015 15:14:43 Got connection from client 127.0.0.1
      11/08/2015 15:14:43 other clients:
      11/08/2015 15:14:43 Normal socket connection
      11/08/2015 15:14:43 Disabled X server key autorepeat.
      11/08/2015 15:14:43 to force back on run: 'xset r on' (3 times)
      11/08/2015 15:14:43 incr accepted_client=5 for 127.0.0.1:48227 sock=7
      11/08/2015 15:14:43 Client Protocol Version 3.8
      11/08/2015 15:14:43 Protocol version sent 3.8, using 3.8
      11/08/2015 15:14:43 rfbProcessClientSecurityType: executing handler for type 2
      11/08/2015 15:14:46 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFE)
      11/08/2015 15:14:46 Enabling NewFBSize protocol extension for client 127.0.0.1
      11/08/2015 15:14:46 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x574D5669)
      11/08/2015 15:14:46 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFD)
      11/08/2015 15:14:46 Enabling full-color cursor updates for client 127.0.0.1
      11/08/2015 15:14:46 Enabling X-style cursor updates for client 127.0.0.1
      11/08/2015 15:14:46 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFF)
      11/08/2015 15:14:46 Using tight encoding for client 127.0.0.1
      11/08/2015 15:14:48 client useCopyRect: 127.0.0.1 -1
      11/08/2015 15:14:48 client_set_net: 127.0.0.1 0.0001


      My current ~/.vnc/xstartup (I've tried a bunch of variations):



      #!/bin/sh

      export XKL_XMODMAP_DISABLE=1
      unset SESSION_MANAGER
      unset DBUS_SESSION_BUS_ADDRESS

      [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
      [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
      xsetroot -solid grey
      vncconfig -iconic &

      gnome-panel &
      gnome-settings-daemon &
      metacity &
      nautilus &
      gnome-terminal &









      share|improve this question














      I'm trying to run an x11vnc server so that someone can connect remotely to my computer, but I'm having trouble getting it to work. I'm using Ubuntu 14.04 and testing the VNC server by using Vinagre to connect on localhost. I get a login prompt and it accepts the password, but then I just get a black screen. This doesn't seem to be an uncommon problem but I've tried tons of solutions I've found through Google and none of them have worked for me. The x11vnc log doesn't give any indication of errors so I don't know where to begin to figure out what is wrong.



      My x11vnc command:



      x11vnc -xkb -noxrecord -noxfixes -noxdamage -display :1 -auth /var/run/lightdm/root/:1 -usepw -forever -o /var/log/x11vnc.log


      The x11vnc log:



      11/08/2015 15:14:43 Got connection from client 127.0.0.1
      11/08/2015 15:14:43 other clients:
      11/08/2015 15:14:43 Normal socket connection
      11/08/2015 15:14:43 Disabled X server key autorepeat.
      11/08/2015 15:14:43 to force back on run: 'xset r on' (3 times)
      11/08/2015 15:14:43 incr accepted_client=5 for 127.0.0.1:48227 sock=7
      11/08/2015 15:14:43 Client Protocol Version 3.8
      11/08/2015 15:14:43 Protocol version sent 3.8, using 3.8
      11/08/2015 15:14:43 rfbProcessClientSecurityType: executing handler for type 2
      11/08/2015 15:14:46 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFE)
      11/08/2015 15:14:46 Enabling NewFBSize protocol extension for client 127.0.0.1
      11/08/2015 15:14:46 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x574D5669)
      11/08/2015 15:14:46 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFD)
      11/08/2015 15:14:46 Enabling full-color cursor updates for client 127.0.0.1
      11/08/2015 15:14:46 Enabling X-style cursor updates for client 127.0.0.1
      11/08/2015 15:14:46 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFF)
      11/08/2015 15:14:46 Using tight encoding for client 127.0.0.1
      11/08/2015 15:14:48 client useCopyRect: 127.0.0.1 -1
      11/08/2015 15:14:48 client_set_net: 127.0.0.1 0.0001


      My current ~/.vnc/xstartup (I've tried a bunch of variations):



      #!/bin/sh

      export XKL_XMODMAP_DISABLE=1
      unset SESSION_MANAGER
      unset DBUS_SESSION_BUS_ADDRESS

      [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
      [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
      xsetroot -solid grey
      vncconfig -iconic &

      gnome-panel &
      gnome-settings-daemon &
      metacity &
      nautilus &
      gnome-terminal &






      remote-desktop vnc






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Aug 11 '15 at 22:26









      ColinColin

      3484719




      3484719





      bumped to the homepage by Community 5 hours ago


      This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.







      bumped to the homepage by Community 5 hours ago


      This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
























          3 Answers
          3






          active

          oldest

          votes


















          0














          There are some contradictions in your post. x11vnc does not read ~/.vnc/xstartup and does not usually connect to -display :1.



          Usually, you have a standard X11 server already running on your screen, and it is on display :0. It shows your gnome desktop on the monitor. You then run x11vnc to copy what is on this real display to a remote connection.



          Perhaps you mean to use tightvncserver which creates a new non-visible framebuffer in which it draws, and also copies to a remote. It reads ~/.vnc/xstartup.






          share|improve this answer
























          • That's strange. If you google "ubuntu x11vnc screen black" you get tons of links to solutions that involve editing the ~/.vnc/xstartup and others saying it fixed the problem for them. Anyway, I will try tightvncserver, thanks.

            – Colin
            Aug 12 '15 at 16:54





















          0














          If the active virtual terminal is different from that one the X server runs at (e.g. what seems to be your case: You are testing from the same computer, but your vnc viewer runs in a session on another VT than the X server you want to connect to) it does not work. (I just had similar problems, not able to VT-switch anymore but wanting to get to interact with my running X session.)



          It is explained there: http://www.karlrunge.com/x11vnc/faq.html#faq-linuxvc. Quote:




          Q-108: I use Linux Virtual Terminals (VT's) to implement 'Fast User Switching' between users' sessions (e.g. Betty is on Ctrl-Alt-F7, Bobby is on Ctrl-Alt-F8, and Sid is on Ctrl-Alt-F1: they use those keystrokes to switch between their sessions.) How come the view in a VNC viewer connecting to x11vnc is either completely black, doesn't update, or pixels messed up unless the X session x11vnc is attached to is in the active VT?



          This seems to have to do with how applications (the X server processes in this case) must "play nicely" if they are not on the active VT (sometimes called VC for virtual console.) That is, they should not read from the keyboard or mouse or manage the video display unless they have the active VT. Given that it appears the XGetImage() call must ultimately retrieve the framebuffer data from the video hardware itself, it would make sense x11vnc's polling wouldn't work unless the X session had active control of the VT.



          There does not seem to be an easy way to work around this. Even xwd(1) doesn't work in this case (try it.) Something would need to be done at a lower level, say in the XFree86/Xorg X server. Also, using the Shadow Framebuffer (a copy of the video framebuffer is kept in main memory) does not appear to fix the problem (last checked 2007.)



          If no one is sitting at the workstation and you just want to remotely switch the VT over to the one associated with your X session (so x11vnc can poll it correctly), one can use the chvt(1) command, e.g. "chvt 7" for VT #7.







          share|improve this answer

































            0














            I got around this by adding my password in the profile before hitting connect vs responding to the popup after hitting connect.



            There's also a field there for a user name which threw me because I hadn't seen any reference to a user name on the host setup, but I left that blank, just added the password, and that did it.



            Be real, be sober.






            share|improve this answer
























            • "in the profile" ? can you please give steps for what you mean?

              – Jim Ford
              Jan 12 '18 at 14:29












            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "89"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f660350%2fgetting-black-screen-when-connected-with-x11vnc%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            3 Answers
            3






            active

            oldest

            votes








            3 Answers
            3






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            0














            There are some contradictions in your post. x11vnc does not read ~/.vnc/xstartup and does not usually connect to -display :1.



            Usually, you have a standard X11 server already running on your screen, and it is on display :0. It shows your gnome desktop on the monitor. You then run x11vnc to copy what is on this real display to a remote connection.



            Perhaps you mean to use tightvncserver which creates a new non-visible framebuffer in which it draws, and also copies to a remote. It reads ~/.vnc/xstartup.






            share|improve this answer
























            • That's strange. If you google "ubuntu x11vnc screen black" you get tons of links to solutions that involve editing the ~/.vnc/xstartup and others saying it fixed the problem for them. Anyway, I will try tightvncserver, thanks.

              – Colin
              Aug 12 '15 at 16:54


















            0














            There are some contradictions in your post. x11vnc does not read ~/.vnc/xstartup and does not usually connect to -display :1.



            Usually, you have a standard X11 server already running on your screen, and it is on display :0. It shows your gnome desktop on the monitor. You then run x11vnc to copy what is on this real display to a remote connection.



            Perhaps you mean to use tightvncserver which creates a new non-visible framebuffer in which it draws, and also copies to a remote. It reads ~/.vnc/xstartup.






            share|improve this answer
























            • That's strange. If you google "ubuntu x11vnc screen black" you get tons of links to solutions that involve editing the ~/.vnc/xstartup and others saying it fixed the problem for them. Anyway, I will try tightvncserver, thanks.

              – Colin
              Aug 12 '15 at 16:54
















            0












            0








            0







            There are some contradictions in your post. x11vnc does not read ~/.vnc/xstartup and does not usually connect to -display :1.



            Usually, you have a standard X11 server already running on your screen, and it is on display :0. It shows your gnome desktop on the monitor. You then run x11vnc to copy what is on this real display to a remote connection.



            Perhaps you mean to use tightvncserver which creates a new non-visible framebuffer in which it draws, and also copies to a remote. It reads ~/.vnc/xstartup.






            share|improve this answer













            There are some contradictions in your post. x11vnc does not read ~/.vnc/xstartup and does not usually connect to -display :1.



            Usually, you have a standard X11 server already running on your screen, and it is on display :0. It shows your gnome desktop on the monitor. You then run x11vnc to copy what is on this real display to a remote connection.



            Perhaps you mean to use tightvncserver which creates a new non-visible framebuffer in which it draws, and also copies to a remote. It reads ~/.vnc/xstartup.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Aug 12 '15 at 7:44









            meuhmeuh

            2,021615




            2,021615













            • That's strange. If you google "ubuntu x11vnc screen black" you get tons of links to solutions that involve editing the ~/.vnc/xstartup and others saying it fixed the problem for them. Anyway, I will try tightvncserver, thanks.

              – Colin
              Aug 12 '15 at 16:54





















            • That's strange. If you google "ubuntu x11vnc screen black" you get tons of links to solutions that involve editing the ~/.vnc/xstartup and others saying it fixed the problem for them. Anyway, I will try tightvncserver, thanks.

              – Colin
              Aug 12 '15 at 16:54



















            That's strange. If you google "ubuntu x11vnc screen black" you get tons of links to solutions that involve editing the ~/.vnc/xstartup and others saying it fixed the problem for them. Anyway, I will try tightvncserver, thanks.

            – Colin
            Aug 12 '15 at 16:54







            That's strange. If you google "ubuntu x11vnc screen black" you get tons of links to solutions that involve editing the ~/.vnc/xstartup and others saying it fixed the problem for them. Anyway, I will try tightvncserver, thanks.

            – Colin
            Aug 12 '15 at 16:54















            0














            If the active virtual terminal is different from that one the X server runs at (e.g. what seems to be your case: You are testing from the same computer, but your vnc viewer runs in a session on another VT than the X server you want to connect to) it does not work. (I just had similar problems, not able to VT-switch anymore but wanting to get to interact with my running X session.)



            It is explained there: http://www.karlrunge.com/x11vnc/faq.html#faq-linuxvc. Quote:




            Q-108: I use Linux Virtual Terminals (VT's) to implement 'Fast User Switching' between users' sessions (e.g. Betty is on Ctrl-Alt-F7, Bobby is on Ctrl-Alt-F8, and Sid is on Ctrl-Alt-F1: they use those keystrokes to switch between their sessions.) How come the view in a VNC viewer connecting to x11vnc is either completely black, doesn't update, or pixels messed up unless the X session x11vnc is attached to is in the active VT?



            This seems to have to do with how applications (the X server processes in this case) must "play nicely" if they are not on the active VT (sometimes called VC for virtual console.) That is, they should not read from the keyboard or mouse or manage the video display unless they have the active VT. Given that it appears the XGetImage() call must ultimately retrieve the framebuffer data from the video hardware itself, it would make sense x11vnc's polling wouldn't work unless the X session had active control of the VT.



            There does not seem to be an easy way to work around this. Even xwd(1) doesn't work in this case (try it.) Something would need to be done at a lower level, say in the XFree86/Xorg X server. Also, using the Shadow Framebuffer (a copy of the video framebuffer is kept in main memory) does not appear to fix the problem (last checked 2007.)



            If no one is sitting at the workstation and you just want to remotely switch the VT over to the one associated with your X session (so x11vnc can poll it correctly), one can use the chvt(1) command, e.g. "chvt 7" for VT #7.







            share|improve this answer






























              0














              If the active virtual terminal is different from that one the X server runs at (e.g. what seems to be your case: You are testing from the same computer, but your vnc viewer runs in a session on another VT than the X server you want to connect to) it does not work. (I just had similar problems, not able to VT-switch anymore but wanting to get to interact with my running X session.)



              It is explained there: http://www.karlrunge.com/x11vnc/faq.html#faq-linuxvc. Quote:




              Q-108: I use Linux Virtual Terminals (VT's) to implement 'Fast User Switching' between users' sessions (e.g. Betty is on Ctrl-Alt-F7, Bobby is on Ctrl-Alt-F8, and Sid is on Ctrl-Alt-F1: they use those keystrokes to switch between their sessions.) How come the view in a VNC viewer connecting to x11vnc is either completely black, doesn't update, or pixels messed up unless the X session x11vnc is attached to is in the active VT?



              This seems to have to do with how applications (the X server processes in this case) must "play nicely" if they are not on the active VT (sometimes called VC for virtual console.) That is, they should not read from the keyboard or mouse or manage the video display unless they have the active VT. Given that it appears the XGetImage() call must ultimately retrieve the framebuffer data from the video hardware itself, it would make sense x11vnc's polling wouldn't work unless the X session had active control of the VT.



              There does not seem to be an easy way to work around this. Even xwd(1) doesn't work in this case (try it.) Something would need to be done at a lower level, say in the XFree86/Xorg X server. Also, using the Shadow Framebuffer (a copy of the video framebuffer is kept in main memory) does not appear to fix the problem (last checked 2007.)



              If no one is sitting at the workstation and you just want to remotely switch the VT over to the one associated with your X session (so x11vnc can poll it correctly), one can use the chvt(1) command, e.g. "chvt 7" for VT #7.







              share|improve this answer




























                0












                0








                0







                If the active virtual terminal is different from that one the X server runs at (e.g. what seems to be your case: You are testing from the same computer, but your vnc viewer runs in a session on another VT than the X server you want to connect to) it does not work. (I just had similar problems, not able to VT-switch anymore but wanting to get to interact with my running X session.)



                It is explained there: http://www.karlrunge.com/x11vnc/faq.html#faq-linuxvc. Quote:




                Q-108: I use Linux Virtual Terminals (VT's) to implement 'Fast User Switching' between users' sessions (e.g. Betty is on Ctrl-Alt-F7, Bobby is on Ctrl-Alt-F8, and Sid is on Ctrl-Alt-F1: they use those keystrokes to switch between their sessions.) How come the view in a VNC viewer connecting to x11vnc is either completely black, doesn't update, or pixels messed up unless the X session x11vnc is attached to is in the active VT?



                This seems to have to do with how applications (the X server processes in this case) must "play nicely" if they are not on the active VT (sometimes called VC for virtual console.) That is, they should not read from the keyboard or mouse or manage the video display unless they have the active VT. Given that it appears the XGetImage() call must ultimately retrieve the framebuffer data from the video hardware itself, it would make sense x11vnc's polling wouldn't work unless the X session had active control of the VT.



                There does not seem to be an easy way to work around this. Even xwd(1) doesn't work in this case (try it.) Something would need to be done at a lower level, say in the XFree86/Xorg X server. Also, using the Shadow Framebuffer (a copy of the video framebuffer is kept in main memory) does not appear to fix the problem (last checked 2007.)



                If no one is sitting at the workstation and you just want to remotely switch the VT over to the one associated with your X session (so x11vnc can poll it correctly), one can use the chvt(1) command, e.g. "chvt 7" for VT #7.







                share|improve this answer















                If the active virtual terminal is different from that one the X server runs at (e.g. what seems to be your case: You are testing from the same computer, but your vnc viewer runs in a session on another VT than the X server you want to connect to) it does not work. (I just had similar problems, not able to VT-switch anymore but wanting to get to interact with my running X session.)



                It is explained there: http://www.karlrunge.com/x11vnc/faq.html#faq-linuxvc. Quote:




                Q-108: I use Linux Virtual Terminals (VT's) to implement 'Fast User Switching' between users' sessions (e.g. Betty is on Ctrl-Alt-F7, Bobby is on Ctrl-Alt-F8, and Sid is on Ctrl-Alt-F1: they use those keystrokes to switch between their sessions.) How come the view in a VNC viewer connecting to x11vnc is either completely black, doesn't update, or pixels messed up unless the X session x11vnc is attached to is in the active VT?



                This seems to have to do with how applications (the X server processes in this case) must "play nicely" if they are not on the active VT (sometimes called VC for virtual console.) That is, they should not read from the keyboard or mouse or manage the video display unless they have the active VT. Given that it appears the XGetImage() call must ultimately retrieve the framebuffer data from the video hardware itself, it would make sense x11vnc's polling wouldn't work unless the X session had active control of the VT.



                There does not seem to be an easy way to work around this. Even xwd(1) doesn't work in this case (try it.) Something would need to be done at a lower level, say in the XFree86/Xorg X server. Also, using the Shadow Framebuffer (a copy of the video framebuffer is kept in main memory) does not appear to fix the problem (last checked 2007.)



                If no one is sitting at the workstation and you just want to remotely switch the VT over to the one associated with your X session (so x11vnc can poll it correctly), one can use the chvt(1) command, e.g. "chvt 7" for VT #7.








                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Sep 9 '15 at 7:14

























                answered Sep 9 '15 at 7:07









                Golar RamblarGolar Ramblar

                1335




                1335























                    0














                    I got around this by adding my password in the profile before hitting connect vs responding to the popup after hitting connect.



                    There's also a field there for a user name which threw me because I hadn't seen any reference to a user name on the host setup, but I left that blank, just added the password, and that did it.



                    Be real, be sober.






                    share|improve this answer
























                    • "in the profile" ? can you please give steps for what you mean?

                      – Jim Ford
                      Jan 12 '18 at 14:29
















                    0














                    I got around this by adding my password in the profile before hitting connect vs responding to the popup after hitting connect.



                    There's also a field there for a user name which threw me because I hadn't seen any reference to a user name on the host setup, but I left that blank, just added the password, and that did it.



                    Be real, be sober.






                    share|improve this answer
























                    • "in the profile" ? can you please give steps for what you mean?

                      – Jim Ford
                      Jan 12 '18 at 14:29














                    0












                    0








                    0







                    I got around this by adding my password in the profile before hitting connect vs responding to the popup after hitting connect.



                    There's also a field there for a user name which threw me because I hadn't seen any reference to a user name on the host setup, but I left that blank, just added the password, and that did it.



                    Be real, be sober.






                    share|improve this answer













                    I got around this by adding my password in the profile before hitting connect vs responding to the popup after hitting connect.



                    There's also a field there for a user name which threw me because I hadn't seen any reference to a user name on the host setup, but I left that blank, just added the password, and that did it.



                    Be real, be sober.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered Jun 30 '16 at 17:28









                    WSmartWSmart

                    1




                    1













                    • "in the profile" ? can you please give steps for what you mean?

                      – Jim Ford
                      Jan 12 '18 at 14:29



















                    • "in the profile" ? can you please give steps for what you mean?

                      – Jim Ford
                      Jan 12 '18 at 14:29

















                    "in the profile" ? can you please give steps for what you mean?

                    – Jim Ford
                    Jan 12 '18 at 14:29





                    "in the profile" ? can you please give steps for what you mean?

                    – Jim Ford
                    Jan 12 '18 at 14:29


















                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Ask Ubuntu!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f660350%2fgetting-black-screen-when-connected-with-x11vnc%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    GameSpot

                    日野市

                    Tu-95轟炸機