Return to Level1Techs.com

Define default screen for Looking Glass Client? (Monitor 2, instead of 1/Default)

Hi,

I’m currently on the B1-branch, and it’s working fine. Actually i was surprised about all the new things, including the readme-stuff. Thanks! That’s great. I didn’t touch my VM for a while (which actually is a full powered Windows 10 on a dedicated NVMe-storage, which i’m booting directly off, from time to time - and other times, within my Linux-system), after moving from Mint to Manjaro.
I hope have someone did come out with some good idéa for the new logo, and a wiki! :slight_smile:

My problem/wish?
I’ve a minor problem, but i simply can’t spot an option for that in the Looking Glass Client.

I would like to start my Looking Glass Client at Monitor 2, instead of the Monitor 1/The primary one.

I spotted the option called win:position, but it sounds move like the position on the targeted screen. I’m already starting the client as borderless+fullscreen, so that’s why i would like to bring it up on Monitor 2 as pr. default in my ~/.looking-glass-client.ini-file.

Is there a build in function to start the client on Monitor 2, instead of Monitor 1, or should i instead, look for a dumb script in KDE? (I’m on the latest beta-release of Manjaro).

Thanks again, and hopefully something are able to help me out :slight_smile:

Updated: Extra And now that you looked by, i’m actually experiences some off color-issues, after installing the client from the B1-branch. To me, it looks a bit overexposed, but i’m not sure that the proper english term is :smiley:

Hi @exetico. The win:position should let you do what you want, I don’t think that SDL2 (the SDK we are using) is capable of specifying a monitor directly. I am out of the country for a few weeks so I wont be able to look until then I am sorry.

As for the over exposure, you might have turned on the Night Vision feature by accident. Press ScrLck+N to toggle it.

1 Like

Thanks for the fast response. Sadly i didn’t find time to answer before now.

I’ve grapped the source-code to find out, what’s related to params.position, however, i can’t find anything related to “params.position” in config.c.

But after taking a look the win.position-module, i at least found optPosValues and optPosToString, which helps me think a bit…

With optPosToStrin i could see that the position is defined as %dx%d, and within optPosValuesi can see: stringlist_push(sl, "<left>x<top>, ie: 100x100");, so that’s perfect.


TL;DR:

[win]
position=2560x0

It did the trick. I’m not quite sure, why i didn’t try that before looking through the code :laughing:
Guess i was all the way too tired at that time. Maybe it would make sense to have it in the documentation.

Also, ScrLck+N did the trick - so it was night vision. However, i had added nvGain=1 to the config, after checking that our… All the way to tired, i guess…

Regarding the support within SDL 2.0, here is a bit of stuff related to that:

Maybe this answer could be usefull. UsingSDL_GetNumVideoDisplays to get the count, SDL_GetDisplayBounds to get the proper information in a loop, but only allow it to run to the screennumer defined by the user, and simply adding up the pixels for both high and width, and use that…

And… Enjoy the days off, if you’re that lucky :wink:


Bonus-question (Mouse+Keyboard auto input target switch between my VM and Linux desktop):

I’m using pass-through of both my keyboard and mice, and trigger it with Ctrl+Ctrl (Recommended in the Arch Wiki).

Do you know, if there is some tricks available, so my machine can auto-switch from my Looking Glass session, to my Linux desktop, while sticking to pass-through, instead of spice (or other 3rd party options - i guess LTT would definitely scream Synergy…).

I’m trying to limit all possible latency-factors :smiley: A very cool thing could be, if Looking Glass was able to handle that (as it can with Spice - i used that back on Linux Mint).


Bonus-info/bug
In Manjaro, while mouse and keybord is pass-through to my VM, and Looking Glass is running, Manjaro is still locking my screen after X minutes, due to inactivity. Maybe there’s an option to have the client securing that the host system arn’t locking the screen, if it’s running, or something like that? I’m not sure what the proper solution is. I know that it could be resolved by going with Spice instead - but that was not my plan :slight_smile: