Page 2 of 2 FirstFirst 12
Results 11 to 20 of 20

Thread: Help locally displaying KDE desktop via x11vnc piped through ssh from Tumbleweed headless remote PC?

  1. #11
    Join Date
    Mar 2008
    Location
    Phuket, Thailand
    Posts
    27,144
    Blog Entries
    40

    Default Re: Help locally displaying KDE desktop via x11vnc piped through ssh from Tumbleweed headless remote

    Quote Originally Posted by arvidjaar View Post
    SDDM is using file with random name to store magic cookie ($XAUTHORITY) instead of default file location and you need to use x11vnc parameter -auth with correct filename. To get it you could use something like this hack:
    Code:
    systemctl --user show-environment  | grep XAUTHORITY= | cut -d'=' -f2
    And x11vnc even displays the whole page of hints why connection may have failed after those lines you have shown and that you gratuitously removed. The first thing those hints mention is correct -auth parameter.
    Thanks. That partly worked. See below ... (where I changed the authentication file name to xauth_XXXXX for the purpose of this post):
    Code:
    oldcpu@oldcorei7:~> systemctl --user show-environment  | grep XAUTHORITY= | cut -d'=' -f2
    /run/user/1000/xauth_XXXXX
    oldcpu@oldcorei7:~> exit
    logout
    Connection to 192.168.2.102 closed.
    oldcpu@X1-Carbon-G9:~> ssh -t -L 5900:localhost:5900 oldcpu@192.168.2.102 'x11vnc -localhost -nolookup -nopw -ncache 10 -noxdamage -auth /run/user/1000/xauth_XXXXX -display :0'
    Password: 
    13/01/2022 11:22:25 x11vnc version: 0.9.16 lastmod: 2019-01-05  pid: 5886
    13/01/2022 11:22:25 Using X display :0
    13/01/2022 11:22:25 rootwin: 0x50e reswin: 0x800001 dpy: 0x66ecc220
    13/01/2022 11:22:25 
    13/01/2022 11:22:25 ------------------ USEFUL INFORMATION ------------------
    13/01/2022 11:22:25 
    13/01/2022 11:22:25 Wireframing: -wireframe mode is in effect for window moves.
    13/01/2022 11:22:25   If this yields undesired behavior (poor response, painting
    13/01/2022 11:22:25   errors, etc) it may be disabled:
    13/01/2022 11:22:25    - use '-nowf' to disable wireframing completely.
    13/01/2022 11:22:25    - use '-nowcr' to disable the Copy Rectangle after the
    13/01/2022 11:22:25      moved window is released in the new position.
    13/01/2022 11:22:25   Also see the -help entry for tuning parameters.
    13/01/2022 11:22:25   You can press 3 Alt_L's (Left "Alt" key) in a row to 
    13/01/2022 11:22:25   repaint the screen, also see the -fixscreen option for
    13/01/2022 11:22:25   periodic repaints.
    13/01/2022 11:22:25 
    13/01/2022 11:22:25 XFIXES available on display, resetting cursor mode
    13/01/2022 11:22:25   to: '-cursor most'.
    13/01/2022 11:22:25   to disable this behavior use: '-cursor arrow'
    13/01/2022 11:22:25   or '-noxfixes'.
    13/01/2022 11:22:25 using XFIXES for cursor drawing.
    13/01/2022 11:22:25 GrabServer control via XTEST.
    13/01/2022 11:22:25 
    13/01/2022 11:22:25 Scroll Detection: -scrollcopyrect mode is in effect to
    13/01/2022 11:22:25   use RECORD extension to try to detect scrolling windows
    13/01/2022 11:22:25   (induced by either user keystroke or mouse input).
    13/01/2022 11:22:25   If this yields undesired behavior (poor response, painting
    13/01/2022 11:22:25   errors, etc) it may be disabled via: '-noscr'
    13/01/2022 11:22:25   Also see the -help entry for tuning parameters.
    13/01/2022 11:22:25   You can press 3 Alt_L's (Left "Alt" key) in a row to 
    13/01/2022 11:22:25   repaint the screen, also see the -fixscreen option for
    13/01/2022 11:22:25   periodic repaints.
    13/01/2022 11:22:25 
    13/01/2022 11:22:25 Client Side Caching: -ncache mode is in effect to provide
    13/01/2022 11:22:25   client-side pixel data caching.  This speeds up
    13/01/2022 11:22:25   iconifying/deiconifying windows, moving and raising
    13/01/2022 11:22:25   windows, and reposting menus.  In the simple CopyRect
    13/01/2022 11:22:25   encoding scheme used (no compression) a huge amount
    13/01/2022 11:22:25   of extra memory (20-100MB) is used on both the server and
    13/01/2022 11:22:25   client sides.  This mode works with any VNC viewer.
    13/01/2022 11:22:25   However, in most you can actually see the cached pixel
    13/01/2022 11:22:25   data by scrolling down, so you need to re-adjust its size.
    13/01/2022 11:22:25   See http://www.karlrunge.com/x11vnc/faq.html#faq-client-caching.
    13/01/2022 11:22:25   If this mode yields undesired behavior (poor response,
    13/01/2022 11:22:25   painting errors, etc) it may be disabled via: '-ncache 0'
    13/01/2022 11:22:25   You can press 3 Alt_L's (Left "Alt" key) in a row to 
    13/01/2022 11:22:25   repaint the screen, also see the -fixscreen option for
    13/01/2022 11:22:25   periodic repaints.
    13/01/2022 11:22:25 
    13/01/2022 11:22:25 XKEYBOARD: number of keysyms per keycode 7 is greater
    13/01/2022 11:22:25   than 4 and 52 keysyms are mapped above 4.
    13/01/2022 11:22:25   Automatically switching to -xkb mode.
    13/01/2022 11:22:25   If this makes the key mapping worse you can
    13/01/2022 11:22:25   disable it with the "-noxkb" option.
    13/01/2022 11:22:25   Also, remember "-remap DEAD" for accenting characters.
    13/01/2022 11:22:25 
    13/01/2022 11:22:25 X FBPM extension not supported.
    Xlib:  extension "DPMS" missing on display ":0".
    13/01/2022 11:22:25 X display is not capable of DPMS.
    13/01/2022 11:22:25 --------------------------------------------------------
    13/01/2022 11:22:25 
    13/01/2022 11:22:25 Default visual ID: 0x21
    13/01/2022 11:22:25 Read initial data from X display into framebuffer.
    13/01/2022 11:22:25 initialize_screen: fb_depth/fb_bpp/fb_Bpl 24/32/5120
    13/01/2022 11:22:25 
    13/01/2022 11:22:25 X display :0 is 32bpp depth=24 true color
    13/01/2022 11:22:25 
    13/01/2022 11:22:25 Autoprobing TCP port 
    13/01/2022 11:22:25 Autoprobing selected TCP port 5900
    13/01/2022 11:22:25 Autoprobing TCP6 port 
    13/01/2022 11:22:25 rfbListenOnTCP6Port: error in bind IPv6 socket: Cannot assign requested address
    ... deleted MANY duplicates of above line
    13/01/2022 11:22:25 rfbListenOnTCP6Port: error in bind IPv6 socket: Cannot assign requested address
    13/01/2022 11:22:25 Failure autoprobing: Cannot assign requested address
    13/01/2022 11:22:25 listen6: bind: Cannot assign requested address
    13/01/2022 11:22:25 Not listening on IPv6 interface.
    13/01/2022 11:22:25 
    13/01/2022 11:22:25 Xinerama is present and active (e.g. multi-head).
    13/01/2022 11:22:25 Xinerama: number of sub-screens: 1
    13/01/2022 11:22:25 Xinerama: no blackouts needed (only one sub-screen)
    13/01/2022 11:22:25 
    13/01/2022 11:22:25 fb read rate: 1403 MB/sec
    13/01/2022 11:22:25 fast read: reset -wait  ms to: 10
    13/01/2022 11:22:25 fast read: reset -defer ms to: 10
    13/01/2022 11:22:25 The X server says there are 10 mouse buttons.
    13/01/2022 11:22:25 screen setup finished.
    13/01/2022 11:22:25 
    
    The VNC desktop is:      localhost:0
    PORT=5900
    13/01/2022 11:22:38 Got connection from client 127.0.0.1
    13/01/2022 11:22:38   0 other clients
    13/01/2022 11:22:38 Normal socket connection
    13/01/2022 11:22:38 check_access: client 127.0.0.1 matches host 127.0.0.1
    13/01/2022 11:22:38 Disabled X server key autorepeat.
    13/01/2022 11:22:38   to force back on run: 'xset r on' (3 times)
    13/01/2022 11:22:38 incr accepted_client=1 for 127.0.0.1:34656  sock=9
    13/01/2022 11:22:38 Client Protocol Version 3.8
    13/01/2022 11:22:38 Protocol version sent 3.8, using 3.8
    13/01/2022 11:22:38 Send channel security type 'none'
    13/01/2022 11:22:38 rfbProcessClientSecurityType: executing handler for type 1
    13/01/2022 11:22:38 rfbProcessClientSecurityType: returning securityResult for client rfb version >= 3.8
    13/01/2022 11:22:38 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEC6)
    13/01/2022 11:22:38 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x574D5664)
    13/01/2022 11:22:38 Enabling full-color cursor updates for client 127.0.0.1
    13/01/2022 11:22:38 Enabling X-style cursor updates for client 127.0.0.1
    13/01/2022 11:22:38 Enabling NewFBSize protocol extension for client 127.0.0.1
    13/01/2022 11:22:38 Enabling ExtDesktopSize protocol extension for client 127.0.0.1
    13/01/2022 11:22:38 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFB)
    13/01/2022 11:22:38 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x574D5668)
    13/01/2022 11:22:38 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFECD)
    13/01/2022 11:22:38 Enabling LastRect protocol extension for client 127.0.0.1
    13/01/2022 11:22:38 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xC0A1E5CE)
    13/01/2022 11:22:38 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEC7)
    13/01/2022 11:22:38 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEC8)
    13/01/2022 11:22:38 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEFE)
    13/01/2022 11:22:38 Using compression level 2 for client 127.0.0.1
    13/01/2022 11:22:38 Using image quality level 8 for client 127.0.0.1
    13/01/2022 11:22:38 Using JPEG subsampling 0, Q92 for client 127.0.0.1
    13/01/2022 11:22:38 Using tight encoding for client 127.0.0.1
    13/01/2022 11:22:38 Sending rfbEncodingExtDesktopSize for size (1280x12288) 
    13/01/2022 11:22:38 Client requested resolution change to (1280x1081)
    13/01/2022 11:22:38 Sending rfbEncodingExtDesktopSize for size (1280x12288) resize prohibited
    13/01/2022 11:22:38 client 1 network rate 5188.4 KB/sec (661403.4 eff KB/sec)
    13/01/2022 11:22:38 client 1 latency:  2.2 ms
    13/01/2022 11:22:38 dt1: 0.0608, dt2: 0.0354 dt3: 0.0022 bytes: 493554
    13/01/2022 11:22:38 link_rate: LR_LAN - 2 ms, 5188 KB/s
    13/01/2022 11:22:38 copy_tiles: allocating first_line at size 41
    13/01/2022 11:22:38 client_set_net: 127.0.0.1  0.0000
    13/01/2022 11:22:42 set_ncache_xrootpmap: trying root background
    13/01/2022 11:22:42 snapshotting background...
    13/01/2022 11:22:42 done.
    13/01/2022 11:22:47 created selwin: 0x80002e
    13/01/2022 11:22:47 called initialize_xfixes()
    I then ran in a different bash shell on my local PC :
    Code:
    oldcpu@X1-Carbon-G9:~> vncviewer encodings "tight copyrect hextile" localhost:0
    
    TigerVNC Viewer 64-bit v1.10.1
    Copyright (C) 1999-2019 TigerVNC Team and many others (see README.rst)
    See https://www.tigervnc.org for information on TigerVNC.
    
    Thu Jan 13 11:22:37 2022
     DecodeManager: Detected 8 CPU core(s)
     DecodeManager: Creating 4 decoder thread(s)
     CConn:       Connected to host localhost port 5900
    
    Thu Jan 13 11:22:38 2022
     CConnection: Server supports RFB protocol version 3.8
     CConnection: Using RFB protocol version 3.8
     CConnection: Choosing security type None(1)
     CConn:       Using pixel format depth 24 (32bpp) little-endian rgb888
     CConn:       SetDesktopSize failed: 1
    So I have the KDE desktop showing remotely ... However the remote session does not recognize my keyboard - only mouse moves.

    Maybe I need to use "-noxkb" option. ...

    I'm going to check the Xorg.0.log file and then possibly reboot that PC and try again.

    I am getting close.

    Thanks for the help.

    [Edit : re: the ipv6 errors - I have that deliberately disabled]
    Last edited by oldcpu; 12-Jan-2022 at 21:38.

  2. #12
    Join Date
    Mar 2008
    Location
    Phuket, Thailand
    Posts
    27,144
    Blog Entries
    40

    Default Re: Help locally displaying KDE desktop via x11vnc piped through ssh from Tumbleweed headless remote

    Quote Originally Posted by oldcpu View Post
    So I have the KDE desktop showing remotely ... However the remote session does not recognize my keyboard - only mouse moves.
    My mistake.

    The keyboard does 'partly' work .. but the session comes up with KDE running with root permissions.

    Opening a konsole and it asks for a password. Entering the root password and it works, but CAPS do not yet work. ....

    I am still scoping the quirks here ... obviously I have something wrong, albeit its interesting to be able to remotely display the KDE desktop ... I just need to revert it back to a regular user. .... Given I ssh and login as a regular user I don't understand why the desktop comes up as root (albeit it does ask for a password). .... Puzzling.

  3. #13
    Join Date
    Mar 2008
    Location
    Phuket, Thailand
    Posts
    27,144
    Blog Entries
    40

    Default Re: Help locally displaying KDE desktop via x11vnc piped through ssh from Tumbleweed headless remote

    I noted further, that I need to obtain the authentication for each reboot of this Tumbleweed system (as it changes)
    Code:
    systemctl --user show-environment  | grep XAUTHORITY= | cut -d'=' -f2
    ... and then use that in the ssh command that runs x11vnc. If this is an ssdm display manager characteristic, I prefer not to do such.

    so I guess next will be to check a different display manager: https://en.opensuse.org/SDB:Change_Display_Manager

    I feel like I am 6 decades younger, learning all these new things.

  4. #14
    Join Date
    Mar 2008
    Location
    Phuket, Thailand
    Posts
    27,144
    Blog Entries
    40

    Default Re: Help locally displaying KDE desktop via x11vnc piped through ssh from Tumbleweed headless remote

    Quote Originally Posted by oldcpu View Post
    Opening a konsole and it asks for a password. Entering the root password and it works, but CAPS do not yet work. ....
    A refinement to this. "shift" "key" does not bring caps (still lower case), but if I press "CapsLock" then all subsequent letters will be capitals until I press "CapsLock" again. ... Interesting.

    I guess the keyboard mapping is not so good (this is using my Lenovo X1 Carbon Generation-9 laptop (running openSUSE LEAP-15.3) to access this remote Tumbleweed PC.

    I still have yet to switch to a different display manager and test that.
    .

  5. #15
    Join Date
    Mar 2008
    Location
    Phuket, Thailand
    Posts
    27,144
    Blog Entries
    40

    Default Re: Help locally displaying KDE desktop via x11vnc piped through ssh from Tumbleweed headless remote

    Quote Originally Posted by malcolmlewis View Post
    Hi
    Can you try iceWM instead, just to see if it's a system issue or a desktop issue.
    I note on this tumbleweed PC:
    Code:
    oldcorei7:~ # update-alternatives --list default-displaymanager
    /usr/lib/X11/displaymanagers/console
    /usr/lib/X11/displaymanagers/lightdm
    /usr/lib/X11/displaymanagers/sddm
    /usr/lib/X11/displaymanagers/xdm
    I will check YaST for iceWM, as its not nominally on the list.

  6. #16
    Join Date
    Mar 2008
    Location
    Phuket, Thailand
    Posts
    27,144
    Blog Entries
    40

    Default Re: Help locally displaying KDE desktop via x11vnc piped through ssh from Tumbleweed headless remote

    Quote Originally Posted by oldcpu View Post
    I note on this tumbleweed PC:
    ...
    I will check YaST for iceWM, as its not nominally on the list.
    iceWM is installed. I now note:
    Code:
    oldcorei7:~ # /usr/sbin/update-alternatives --list default-xsession.desktop
    /usr/share/xsessions/icewm-session.desktop
    /usr/share/xsessions/plasma5.desktop
    Now to figure out how to switch to it .... ??

    .. although I wonder if it makes more sense to try a different display manager prior to trying a different window manager. ... Which is least intrusive?

  7. #17
    Join Date
    Mar 2008
    Location
    Phuket, Thailand
    Posts
    27,144
    Blog Entries
    40

    Default Re: Help locally displaying KDE desktop via x11vnc piped through ssh from Tumbleweed headless remote

    I am taking a bit of a step back here ... and pondering the way forward.

    I recall now the main reason that I have been using x11vnc all these years, is that it connects to the existing graphical session. This was incredibly useful for a decade, when I lived in Europe, and my mother lived in North America, and I would ssh/x11vnc into her PC in North America, and I would remotely help her and remotely maintain her PC, and she could see what I was doing, and I could see what she was doing.

    Of course, that is no longer the case, and I am now simply trying to connect to a PC in the next room which has no monitor attached ... ie no existing graphical session to connect to. I have read that most other vnc servers will spawn an entirely new graphical session. Maybe that is what I should be doing. ... or maybe I should use x2go.

    Am I making this unnecessarily complex for myself with x11vnc? Maybe now is the time to switch to a different vnc server, or to x2go ? ( all of which I would need to learn from scratch)

    Maybe x11vnc is not the correct way to go about this ...

    Sometimes I am a little slow.
    Last edited by oldcpu; 12-Jan-2022 at 23:45.

  8. #18
    Join Date
    Mar 2008
    Location
    Phuket, Thailand
    Posts
    27,144
    Blog Entries
    40

    Default Re: Help locally displaying KDE desktop via x11vnc piped through ssh from Tumbleweed headless remote

    Quote Originally Posted by oldcpu View Post
    I note on this tumbleweed PC:
    Code:
    oldcorei7:~ # update-alternatives --list default-displaymanager
    /usr/lib/X11/displaymanagers/console
    /usr/lib/X11/displaymanagers/lightdm
    /usr/lib/X11/displaymanagers/sddm
    /usr/lib/X11/displaymanagers/xdm
    I will check YaST for iceWM, as its not nominally on the list.
    While pondering what to do next .... I did a quick switch to lightdm from ssdm.
    Code:
    oldcpu@oldcorei7:~> sudo update-alternatives --set default-displaymanager /usr/lib/X11/displaymanagers/lightdm
    [sudo] password for root: 
    update-alternatives: using /usr/lib/X11/displaymanagers/lightdm to provide /usr/lib/X11/displaymanagers/default-displaymanager (default-displaymanager) in manual mode
    oldcpu@oldcorei7:~>
    I then rebooted the Tumbleweed PC (via 'shutdown -r now' ) and this time I did not need the authentication to loggin ... ie this works :

    In one bash shell on the PC (LEAP-15.3) that I am sitting at:
    Code:
    ssh -t -L 5900:localhost:5900 oldcpu@ip-addess-of-tumbleweed-pc 'x11vnc -localhost -nolookup -nopw -ncache 10 -noxdamage -display :0'
    and then in a second bash shell on this same PC:
    Code:
    vncviewer encodings "tight copyrect hextile" localhost:0
    and it brings up the Tumbleweed KDE on the LEAP-15.3 PC where I am sitting. This time the keyboard 'shift' key works properly.

    However, again the bash shell (and not the desktop) comes up as user root !! in every bash shell on that PC I open. ...Checking the settings I see that in this Tumbleweed update the konsole always comes up as root (as it has "su -" as a default command setting). I changed the profile to be a regular user and now that does not happen.

    I don't know if that (konsole always coming up as user root, asking for a password) was a design decision, but I don't like that approach if it is indeed the intended way forward for Tumbleweed.

  9. #19
    Join Date
    Mar 2008
    Location
    Phuket, Thailand
    Posts
    27,144
    Blog Entries
    40

    Default Re: Help locally displaying KDE desktop via x11vnc piped through ssh from Tumbleweed headless remote

    Quote Originally Posted by oldcpu View Post
    ... ie this works :
    ...
    and it brings up the Tumbleweed KDE on the LEAP-15.3 PC where I am sitting. This time the keyboard 'shift' key works properly.
    ... Tumbleweed update the konsole ... I changed the profile to be a regular user
    I guess I should summarize to note everything now appears to be working as before. ... I am still testing out various aspects of this headless Tumbleweed setup, but at present it appears to be functioning similar to how I remember LEAP-15.2 was working (I did not test its LEAP-15.3 setup very much).

    My thanks to all on this thread who participated and helped me. .... Once again (for me) its been a learning experience.
    Last edited by oldcpu; 13-Jan-2022 at 02:36.

  10. #20

    Default Re: Help locally displaying KDE desktop via x11vnc piped through ssh from Tumbleweed headless remote

    I used x2go. And this is work fine on leap 15.2 and old tumbleweed, But on Leap 15.3 and fresh tumbleweed it did not connect to remote session, or another session. X2go only work in terminal mode. I don't know why this is happen.

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •