Forum Replies Created
-
Posts
-
Just as an additional datapoint, my system too experiences the lack of functionality described here.
I had to write an xrandr wrapper script to run upon connection as a workaround. (which is not ideal of course)
Unable to reproduce the issue after restart of the system.
I /suspect/, actally, that there was a video driver hang. Since I wasn’t able to be at the physical display at the time of this issue, the problem /appeared/ (manifested) itself as a NoMachine issue, but as soon as I got to my physical desktop it was clear the display system was hung.
-> Recently newer versions of the Linux kernel, which Fedora has been releasing, are having issues with nVidia nouveau driver.
Since switching to the proprietary driver the system has been more stable and I’ve not had a problem remotely connecting thus far.
For now, let’s consider this as “not reproducible” or “solved” — I’ll post back if it happens again 😉
Triple confirmed the xflux incompatibility
– when flux is running, NoMachine’s “blank screen” really screwed up (flickers)
– when flux is disabled, the flicker is no longer a problem
NOTE:
– even with flux disabled, there’s still a bit of an awkward situation where the mouse pointer/cursor is STILL visible on the black screen, and it moves around as the remote user works – people physically on premise would be surprised to see a mouse pointer moving around on a black screen 😮
Great questions.
Indeed, 64-bit.
`$ uname -a
Linux ${USER}-lnx-1 4.9.13-101.fc24.x86_64 #1 SMP Tue Mar 7 23:48:32 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
`Wow flux, good point. I had installed this YEARS ago, and it’s just worked forevermore.
`$ ps wauxxx | grep xflux
mcallag+ 5134 0.0 0.0 31952 100 tty2 S+ Mar13 6:53 /home/${USER}/bin/xflux -l 43.48 -g -80.54
mcallag+ 11515 0.0 0.0 118492 932 pts/2 S+ 14:49 0:00 grep –color=auto xflux
$ file /home/${USER}/bin/xflux
/home/${USER}/bin/xflux: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=546afa8b6a16c78da97eef00b561adbfed80721f, not stripped
`Of immediate interest … it’s possible that it isn’t playing nicely with flux in general. I killed the process, and retried.
- Report = screens remain black/bank now! (it helped!)
Remaining Issue:
- monitors at the physical location STILL unfortunately shows the user’s mouse/cursor moving around while they work 🙁
(awkward/annoying still, but at least privacy is retained)
Confirmed, even on latest versions (Linux -> Linux), both running 5.2.11.
1. CONFIRMED: that the system /is/ in fact still locked (although it of course gives away exactly what the user is doing remotely to anyone who turns on the monitors at the physical workstation)
2. YES, i can meet to reproduce problem. Will send mail.
It’s probably worthwhile to document the backwards compatibility which would be lost in doing so. As far as I can interpret from the original post, only Windows XP would be negatively affected (in which case no one probably cares).
My question directly was more out of interest — wondering — what driver replaces the functionality in Win7+ (w.r.t. “a virtual device that mirrors the drawing operations of one or more additional physical display devices“.)