fra81

Forum Replies Created

Viewing 15 posts - 46 through 60 (of 694 total)
  • Author
    Posts
  • in reply to: Could not create a virtual desktop on RHEL 8 #39719
    fra81
    Moderator

    But changing the ‘DefaultDesktopCommand ‘ to the one suggested by you allowed the user to login but the graphics acceleration seems to be missing.

    Acceleration by means of VirtualGL can be enabled either explicitly by the vglrun command (even only for specific applications) or implicitly for the whole desktop by the 'nxserver --virtualgl yes' command. That DefaultDesktopCommand was provided to you assuming you were using the second method. You can find further details in https://kb.nomachine.com/AR05P00982.

    Furthermore, when I used my version of ‘DefaultDesktopCommand ‘only one of my clients with Mac could not create a NoMachine session.

    Can you send the logs from this specific case?

    in reply to: Black screen with mouse showing upon login #39692
    fra81
    Moderator

    @MegaSlonic

    Disabling H.264 solved the issue for Liftaren. Is it the same for you?

     

    And can you both try to check ‘Disable client side hardware decoding’ in the Display settings tab of the menu panel (Modify button)? Is this enough to solve the problem even when using H.264?

    And as Britgirl mentioned, logs would be useful, especially client side logs:

    https://kb.nomachine.com/DT11R00181#2.1

    in reply to: GUI login showing up as incorrect password #39691
    fra81
    Moderator

    Hi,

    it’s not clear to me if you are talking about the username/password you have to enter to connect to the server, or the credentials you have to enter into the remote desktop’s login window (when you are already connected with NoMachine to the Debian machine) to get to the user’s desktop. Can you please clarify on this point?

    That said, would you send us the logs? You can use instructions in https://kb.nomachine.com/DT11R00182 for the server side, and https://kb.nomachine.com/DT11R00181#2.1 for the client side. You can send them to forum[at]nomachine[dot]com by referencing this topic.

    fra81
    Moderator

    When its checked, Player window should automatically lose focus when mouse leaves the window and on mouse enter, it’ll be focus as it is now.

    This is a feature some Operating Systems have, generally called ‘focus follows mouse’. I do believe that the Player window should not interfere with the normal rules imposed by the OS about how the focus is moved, even if it would be possible to do so.

    However, in case you don’t know already, there is a key combination to release the mouse when it is grabbed by the Player window: Ctrl+Alt+Left mouse button. Would this help you?

    fra81
    Moderator

    Hi,

    what you want to achieve is not currently possible and, to be honest, I think it could be unexpected and difficult to understand for most users in the most common setups. Thank you for your interest in NoMachine 🙂

     

    fra81
    Moderator

    Hi,

    it seems like you are in view-only mode. Please check the value of the ‘PhysicalDesktopMode’ key in the ‘/usr/NX/etc/server.cfg’ file, change it to ‘1’ or ‘2’ if necessary, then try again.

    in reply to: Wayland Pipewire screenshare #39167
    fra81
    Moderator

    Hi Whitecatkeke,

    please gather logs while reproducing the problem with pipewire (that is, as you say, the ‘compositor’ option) and send them to forum[at]nomachine[dot]com. You can find instructions in https://kb.nomachine.com/DT11R00182.

    As for ‘egl’, is the Wayland Gnome option reported as available in the login window? What are the exact Manjaro and Gnome versions?

    in reply to: Using Karabiner on macOS #39070
    fra81
    Moderator

    Hello,

    NoMachine transfers the pressed key and injects it on the server at the system level. If we understand how Karabiner is working, doing the remapping of the pressed key to produce a different event, as it remaps the physical key, it should also remap the key injected by NoMachine. Since that’s not the case, it means that Karabiner works at a different level of the device handling stack and that the key NoMachine sends is interpreted by the OS by-passing the capture Karabiner does. Unfortunately we don’t know at which level Karabiner is working, so you should probably try to contact the Karabiner support.

     

    in reply to: Automatic keyboard layout configuration #38979
    fra81
    Moderator

    It would be enough for the client to somehow hint at the local configuration in a way that could be parsed in a desktop start script on the server.

    This is what NoMachine normally does. Do the clients have this problem only when reconnecting to an existing virtual desktop? Or even when creating a new virtual desktop?

    Can you share the logs from one of the problematic sessions?  You can find instructions in https://kb.nomachine.com/DT11R00181. Please also tell what is the expected keyboard layout for that client.

    in reply to: Using NoMachine with a custom keyboard layout #38978
    fra81
    Moderator

    Hi,

    NoMachine doesn’t load the keymaps from the system path (/usr/share/X11/xkb), but it ships its own keyboard config files in /usr/NX/share/X11/xkb. You can try to add the layout file there.

    fra81
    Moderator

    Hi,

    NoMachine doesn’t change the refresh rate explicitly, it just chooses a different resolution among the ones made available by the system in order to fit the size of the NoMachine player window. This is only done if you have the ‘Resize remote display’ option set, which I assume is your case, otherwise no change should occur on the remote system.

    It would be interesting to know the system configuration at the time the problem is reproduced. Could you try to reproduce again, run the ‘xrandr -q’ command on the server and show us the output?

    in reply to: Uncompressed Option i.e. no-encoding #38816
    fra81
    Moderator

    As we said, we believe using uncompressed streams over any network, in a software like NoMachine makes no sense, but we will surely explore both of these, as soon as they become more widespread, as we always do with any new advancements and any new technologies ;-).

    in reply to: Uncompressed Option i.e. no-encoding #38813
    fra81
    Moderator

    In theory yes, in practice unfortunately not. It’s true that 49 ms needed to transfer the same frame, on a 1 Gbps network, would become 4.9 ms, on a 10 Gbps network, but this is only in theory. In practice moving the data from the network layer to the video RAM is much, much more expensive. We did our experimentation, of course, and the real frame-rate that we were able to achieve, with uncompressed data, on a 10 Gbps network, with a dedicated switch, with only the client and server on the physical layer, were close to 20 frames-per-second. And this only at times, with a sustained rate much lower than that. And this with the code that is inside the production NoMachine software, code that is optimized to be zero-copy (except the copy from the network layer to the video RAM, of course). The fact is that data-tranfers are expensive. Operating systems can use DMA, but doing that in user-level code is basically impossible and, even if it was possible, it would only be at conditions that would greatly reduce the number of systems where the “feature” can be leveraged and users make real use of it. The point, in the end, is that even if we did such “uncompressed encoding”, and even if it worked, it would be of so little use for almost the totality of our users that it would just be a quirk, something to mess about with. Different is the approach we have taken, the continued work on algorithmically improving the “end quality” of the output, so much to appear visually lossless.

    in reply to: Uncompressed Option i.e. no-encoding #38809
    fra81
    Moderator

    Hi 🙂

    Let’s do some math considering a 1Gbps Ethernet connection and a screen resolution of 1280*960, which, you will agree, is pretty low for today’s standards.

    For a start, we can calculate how many MBs can be transferred on the network per second:

    (1000000000 / 10) / 1024 = 97656.25

    1Gbps = 97.656MBs

    The size of a single 1280×960 frame is given by:

    (1280 * 960 * 4) / 1024 = 4800.00

    Size of 1 frame = 4.8MB

    Now we can calculate how many frames can be transferred on the network per second:

    97656.25 / 4800.00 = 20.34

    It is possible to transfer 20.34 frames per second, which is very far from the 60 fps that would be considered a good frame rate.

    We can also calculate how much time is needed to transfer a single frame, that will directly affect the latency:

    1000 / 20.34 = 49.16

    So it takes 49.16 ms to transfer a single frame through the Ethernet. This considering a direct gigabit Ethernet link between only the two computers. Any other computer on the same network could add more latency. And we can easily imagine what could happen with a FullHD (1920×1080) or a 4K resolution.

    This explains why what you say makes perfectly sense in theory but not really in practice. It is far better making the CPU and GPU do the work to reduce the transferred size, as they will always be faster than any network.

    in reply to: Media sometimes plays faster #38488
    fra81
    Moderator

    Hi,

    I’m not sure I understand the scenario. Are you playing a video on the server and watching it on the client through the NoMachine connection? Can you provide some more details?

    If you could record a video showing the issue, that would be very useful.

Viewing 15 posts - 46 through 60 (of 694 total)