1

Lubuntu 18.04 with 3 monitors on an nVidia graphics card:

enter image description here

The desk, however, only has 2 physical screens. The left and center monitors are connected normally - 1 port to 1 cord to 1 screen - but the right one goes through a switch/splitter that (among other things) feeds a broadcast display that doesn't need to be seen locally. So the rightmost of these 3 monitors is not normally visible. It can be seen if needed - one of the switch/splitter's outputs goes to a second input of the right physical screen - but it takes some work, and you kinda have to "just know" that that's why you can't see something.

And of course, the default place for the mouse pointer on system startup is just on the right side of the boundary between the right two monitors, which is just off the edge of the physically viewable area. Thus, the automatic update window appears over there and can't be seen except for its button on the taskbar.

I don't want to forbid the use of that monitor entirely, because I want the production software's output window to go there automatically, which it presently does. But is there a way to put the mouse pointer on startup, and the update window, somewhere visible?


Update: @pierrely's suggestion of xdotool is almost what I'm looking for. It works perfectly in the terminal, but does nothing on startup. (at least, nothing visible)

This script:

#!/bin/bash

# Triggered from:
# Menu -> Preferences -> Default applications for LXSession -> Autostart

sleep 10
echo >> /home/hrcc/Desktop/debug.log

# Put the mouse pointer somewhere sensible (not on the far-right broadcast screen)

date                           >> /home/hrcc/Desktop/debug.log
whoami                         >> /home/hrcc/Desktop/debug.log
xdotool mousemove --sync 10 10 >> /home/hrcc/Desktop/debug.log 2>>&1
date                           >> /home/hrcc/Desktop/debug.log

exit 0

Produces this logfile:

Mon Jul 13 13:50:36 CDT 2020
hrcc

So it appears as if xdotool knows it's not working and blocks like the --sync option tells it to, but I'd kinda like it to work.

8
  • just some tips.... get the monitors id with xrandr and grep (eg "primaryscreen=$(xrandr | grep primary | cut -d " " -f1)" for the primary screen.... determine your coordinates, then use xdotool to move the mouse to that screen and those coordinates. "xdotool mousemove --sync $xcoords 10 --screen $primaryscreen" , put it in a script and put that in your startup (settings, startup, add. either the single line code or the script). screen ID might change on reboots, which is why I set the $screen parameter that way. – pierrely Jul 13 '20 at 5:39
  • @pierrely That almost works. xdotool wasn't installed by default, but sudo apt install xdotool fixed that. Then I was able to simplify it a lot because the far left side of my coordinate system is always visible. So xdotool mousemove 10 10 is enough. That also removes the need to determine the primary screen. BUT...while it works perfectly in the terminal, it doesn't do anything on startup. The --sync option on startup never returns. See edit. – AaronD Jul 13 '20 at 19:03
  • did you put the command in startup , or put a script that runs it in startup? you could test that any command you put in at startup runs by ' touch ~/test.txt ' and see if that empty file is made in your home folder. you might also want to add a delay to the command or script as there might be some other focus that moves the mouse after yours is run as the desktop opens. eg sleep 1000 for 1 second delay ... so ' sleep 1000 && xdotool etc ' – pierrely Jul 14 '20 at 23:12
  • @pierrely It's a script that runs on startup, copy/pasted here. I know it runs because it creates the logfile that is also copy/pasted here. And it does include a 10-second delay up front, as you can see. – AaronD Jul 14 '20 at 23:57
  • maybe you could try doing a mouseclick on the screen first? maybe try an audio beep for further confirmation. xdotool click 1 . sudo apt install beep. linux.die.net/man/1/beep – pierrely Jul 16 '20 at 23:28
0

It would seem like moving some cables around would be the most intuitive answer but:

I don't know what you mean by "startup", during boot?? ...and I don't know what you mean by update window. I think I do, but.....

I don't know what you mean when you mention the "cursor".. again, I think I do but it conflicts with the other things i don't understand. And then I see you're clearly using the graphical Desktop.

are you referring to two different stages? Booting and then Graphical Desktop?

As far as booting:
I am thinking either way, would it not solve the problem by making the card connection connected to the monitor on the right, the card connection connecting to the monitor on the left?.... and then reorganizing the desktop via nvidia settings?

If I am understanding correctly(which i doubt), that screen designation during boot, I believe is selected in bios... and I am not sure if you can change that behavior unless you're using more than one graphics card and selecting between them...(not between connections on the same card. I could be wrong though)

As far as the Desktop:
(I'm using Mate Desktop but) under Preferences --> Look and Feel --> Windows.... On the "Placement" tab, there is one choice of "Center new windows".. it "seems" like you're saying that the window is actually supposed to be on your middle screen since you see the "taskbar button"? Perhaps this will make it visible in the center of that screen.

2
  • Sorry. I had forgotten that "cursor" implies text. I meant the mouse pointer. Updated the question accordingly. – AaronD Jul 13 '20 at 4:31
  • As far as the Desktop, there is one window that I expressly want to appear on that screen, so a global setting to put everything somewhere else doesn't work. Otherwise, it might be an easy fix. – AaronD Jul 13 '20 at 4:34
0

It turned out to be a syntax error, that I wasn't seeing because stdout and stderr from startup scripts aren't automatically visible. I ran my startup script in a terminal, and it gave me an error on the line that didn't work.

On closer inspection, I noticed a double arrow in the redirection of stderr to stdout. (2>>&1) Changed it to a single arrow (2>&1), and it works! Don't even need to sleep at the start.


Also note that the next LTS version, 20.04, has a different display manager, which doesn't have this problem to start with. It puts the pointer at the center of a rectangle that covers all monitors, which is nicely visible for me even with my one monitor not physically hooked up.

I'd been contemplating a distro upgrade anyway, but hesitant because it's a live production machine that MUST work, even if it's a bit out of date. Then a security update broke the display manager...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.