maxim-nomachine

Forum Replies Created

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • maxim-nomachine
    Participant

    ping 192.168.88.1
    ERROR: ld.so: object ‘/usr/NX/lib/libnxegl.so’ from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
    PING 192.168.88.1 (192.168.88.1) 56(84) bytes of data.
    64 bytes from 192.168.88.1: icmp_seq=1 ttl=64 time=1.63 ms
    64 bytes from 192.168.88.1: icmp_seq=2 ttl=64 time=1.11 ms

    I use openSUSE Tumbleweed…

    I tried to look at AppArmor and generate logs via:

    journalctl -g apparmor > apparmor.log

    But latest message was logged 2 days ago.

    So either it is not logged or it is not related to AppArmor.

    in reply to: “Grab the keyboard input” does not work anymore #49018
    maxim-nomachine
    Participant

    Yes, I tried and it does not work in Wayland.

    But VMWare Workstation can successfully grab keyboard input for its window in any DE.

    So grab in VMWare works even for updated KDE >= 6.1.x

    I do not know what other can be considered as a test.

    I will wait version 6.2.0 to check fixed KDE issue: Version Fixed In: 6.2.0

     

    in reply to: “Grab the keyboard input” does not work anymore #48664
    maxim-nomachine
    Participant

    OK, I will check with KDE if you think nothing should be made on NoMachine side.

    Just one question. Should grab work in Wayland session?

    in reply to: “Grab the keyboard input” does not work anymore #48659
    maxim-nomachine
    Participant

    Can you start the player from a terminal instead like this?
    /usr/NX/bin/nxplayer –activegrab

    Check what’s configured in your nxs file because this setting will override your global setting (configured in Player). You can check what’s in the .nxs file by locating it in the directory defined in the ‘Connections and recordings’ field from the Settings -> Player -> Folders panel of the User Interface.

    What is the reason to do that?

    I wrote:

    I assigned custom shortcut Meta+R in System Settings | Shortcuts The app executed in both systems: local and remote (if grab is enabled, if not then only local system).

    Obviously it says that I have the way to confirm if grab was really enabled or not.

    /usr/NX/bin/nxplayer –activegrab

    It was tested before I created this issue. It does not have any effect.

    in reply to: “Grab the keyboard input” does not work anymore #48654
    maxim-nomachine
    Participant

    What is the OS on the nxplayer side?

    The version provided is nxplayer side. Version of the remote one is OpenSUSE Leap 15.6.

    Did you try a reboot on the openSUSE side?

    Yes, both sides. All updates are installed, systems are rebooted.

    Is the issue just the Alt F4 key or other Alt+ combinations?

    I assigned custom shortcut Meta+R in System Settings | Shortcuts

    The app executed in both systems: local and remote (if grab is enabled, if not then only local system).

    Please describe the steps you take to reproduce the behaviour.

    Nothing specific most likely it started to happen after update of local side. Maybe some incompatibility with fresh rolling libs.

    I just tested another environment and it works fine:

    Operating System: openSUSE Tumbleweed 20240621
    KDE Plasma Version: 6.0.5
    KDE Frameworks Version: 6.3.0
    Qt Version: 6.7.1
    Kernel Version: 6.9.5-1-default (64-bit)
    Graphics Platform: X11

    After updating to latest version (zypper dup) it has the same grab input issue. Updated system the same as originally tested one:

    Operating System: openSUSE Tumbleweed 20240625
    KDE Plasma Version: 6.1.0
    KDE Frameworks Version: 6.3.0
    Qt Version: 6.7.2
    Kernel Version: 6.9.6-1-default (64-bit)
    Graphics Platform: X11

    in reply to: Fullscreen and windows management #46119
    maxim-nomachine
    Participant

    I just made setup on 2 Linux PCs. Both openSUSE.

    Behaviour is the same.

    I created connection (myself, discovery is disable), so it is saved NXS file, I connected to server, chosen full screen icon, then disconnected by Alt+F4. Next time window will not be full screen after connection to server (it will be maximized but not full screen).

    If I manually change NXS file here from:

    <option key=”Session window state” value=”normal” />

    to:

    <option key=”Session window state” value=”fullscreen” />

    It reverts value to normal back, even if on close NoMachine client was in full screen.

    Operating System: openSUSE Tumbleweed 20231123
    KDE Plasma Version: 5.27.9
    KDE Frameworks Version: 5.112.0
    Qt Version: 5.15.11
    Kernel Version: 6.6.2-1-default (64-bit)
    Graphics Platform: X11

    in reply to: Fullscreen and windows management #46120
    maxim-nomachine
    Participant

    I was able to workaround it only by KDE itself via “Edit Windows-Specific Settings”.

    I set Force for Full Screen property for nxplayer.bin.

     

    in reply to: Fullscreen and windows management #45439
    maxim-nomachine
    Participant

    How many displays are connected to the client and to the server machines?

    Are you connecting to the physical desktop of a Linux server?

    I can be wrong, but in my opinion it is client settings and not related to server.

    Client simply does not remember windows size.

    But if that matters I tried 2 different machines, 1 headless with [removed], 2nd one with 1 physical monitor, but it is not used and connection is made to VNC session.

     

    As for your second question, the client doesn’t normally close the window with the list of connections while other client windows are running, so I’m not sure about what you’re seeing on Windows.

    On Windows I used previous version of NoMachine, probably 7.x, now I updated to latest one 8.8.1 and situation is the same as on Linux. I think you changed that behaviour. So is it possible to close window with connections automatically after I connection to some server is established?

     

    in reply to: Disable notifications for headless stations #43881
    maxim-nomachine
    Participant

    How to disable such notifications?

    I tried: DisplayMonitorNotifications 0

    It does not help.

     

     

    in reply to: Avoid password after connecting to KDE VNC session #36207
    maxim-nomachine
    Participant

    But I do not have problem with LXQt desktop. And I workarounded it that way.

    And setting up system auto-login on physical machine is not very secure concern.

    in reply to: Avoid password after connecting to KDE VNC session #35368
    maxim-nomachine
    Participant

    I think it is not a screen-saver. It is a lock screen.

Viewing 11 posts - 1 through 11 (of 11 total)