640x480 Ghost screen1 stealing panels and r-click menus
Linux - DesktopThis forum is for the discussion of all Linux Software used in a desktop context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
640x480 Ghost screen1 stealing panels and r-click menus
Hello LinuxQuestions!
I hope this is an apporpriate forum for this question. It has to do with graphics card, but I think it's more software/desktop config. I don't know if it is nvidia, xfce4, xorg, or what. I have only been using GNU/Linux as my daily driver since last summer and have been struggling with this screen issue for months. I decided to finally join a forum to see if someone else has any ideas. I hope I can make it clear and not ramble. I'm not sure what terminology to use.
The Problem
I am having some issues with a 640x480 "ghost screen" that lives in the upper left hand corner of my left monitor, and randomly steals my panels and right-click menus. When I r-click on anything on the right monitor, the menu appears in the upper left of the left monitor.
If I move a panel to the left monitor, it shrinks and gets stuck in the upper left area.
Current work-around
If I open display settings and set to any other resolution, then revert back, it goes back to normal for a while.
I haven't been able to find the trigger. Just intermittent.
A second issue that i assume is related is that my cursor falls off the right side of the right monitor, and doesn't show back up until I move it left all the way to the left monitor. This last issue is not intermittent. It is always the case and is very consistent.
I can move screens around in the nvidia-settings window, but it doesn't help and I'm running out of sacrificial chickens to get things working again afterwards.
I have an nVidia GeForece GTX 690, which has 2 GPUs.
I have 2 monitors attached.
I have the nVidia 470.103.01 driver installed.
I generally keep the system up to date.
Using XFCE4 desktop
nVidia-settings interface says that screen 0 is assigned GPU0 and both monitors and has a size of 3840x1080 (2*(1920)x1080).
Screen 1 has GPU1, no monitors and a size of 640x480. I assume this is the area in the upper left of my left monitor.
It seems it is only using GPU0 and GPU1 is ignored.
I don't see a way to adjust anything in the nvidia gui, and I don't understand xorg.conf well enough to adjust anything or even if that is the problem. I tried adjusting xorg.conf, but had to cp the backup back,and restart X11 from tty1.
I don't know what info would help. I've added the xorg.conf and xrandr, but when I added the /var/log/Xorg.0.log I went over the post's char limit of 30k.
I am hoping someone can point me towards tools and knowledge I can use to troubleshoot graphics issues like this. I don't know what I need to search for on this problem. Haven't had any luck finding info other than high level superficial or unrelated stuff.
Here in the log you can see the 640x480 screen, but it doesn't show in xrandr or xorg.conf below, cat /var/log/Xorg.0.log|grep -n3 -i screen
Code:
14-[ 39025.245] (==) Using config file: "/etc/X11/xorg.conf"
15-[ 39025.245] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
16-[ 39025.245] (==) ServerLayout "Layout0"
17:[ 39025.245] (**) |-->Screen "Screen0" (0)
18-[ 39025.245] (**) | |-->Monitor "Monitor0"
19-[ 39025.245] (**) | |-->Device "Device0"
20:[ 39025.245] (**) |-->Screen "Screen1" (1)
21-[ 39025.245] (**) | |-->Monitor "Monitor1"
22-[ 39025.245] (**) | |-->Device "Device1"
23-[ 39025.246] (**) |-->Input Device "Keyboard0"
--
134-[ 39025.595] (--) NVIDIA(GPU-0):
135-[ 39025.600] (II) NVIDIA(0): Validated MetaModes:
136-[ 39025.600] (II) NVIDIA(0): "1920x1080+0+0"
137:[ 39025.600] (II) NVIDIA(0): Virtual screen size determined to be 1920 x 1080
138-[ 39025.603] (--) NVIDIA(0): DPI set to (95, 94); computed from "UseEdidDpi" X config
139-[ 39025.603] (--) NVIDIA(0): option
140-[ 39025.603] (**) NVIDIA(1): Depth 24, (--) framebuffer bpp 32
--
175-[ 39025.793] (--) NVIDIA(1): AllowEmptyInitialConfiguration is enabled
176-[ 39025.794] (II) NVIDIA(1): Validated MetaModes:
177-[ 39025.794] (II) NVIDIA(1): "NULL"
178:[ 39025.794] (II) NVIDIA(1): Virtual screen size determined to be 640 x 480
179-[ 39025.794] (WW) NVIDIA(1): Unable to get display device for DPI computation.
180-[ 39025.794] (==) NVIDIA(1): DPI set to (75, 75); computed from built-in default
181-[ 39025.794] (II) NVIDIA: Reserving 6144.00 MB of virtual memory for indirect memory
--
231-[ 39025.912] (II) Initializing extension RANDR
232-[ 39025.913] (II) Initializing extension COMPOSITE
233-[ 39025.913] (II) Initializing extension DAMAGE
234:[ 39025.913] (II) Initializing extension MIT-SCREEN-SAVER
235-[ 39025.913] (II) Initializing extension DOUBLE-BUFFER
236-[ 39025.913] (II) Initializing extension RECORD
237-[ 39025.913] (II) Initializing extension DPMS
--
245-[ 39025.913] (II) Initializing extension GLX
246-[ 39025.913] (II) Initializing extension GLX
247-[ 39025.913] (II) Indirect GLX disabled.
248:[ 39025.913] (II) GLX: Another vendor is already registered for screen 0
249:[ 39025.913] (II) GLX: Another vendor is already registered for screen 1
250-[ 39025.913] (II) Initializing extension XFree86-VidModeExtension
251-[ 39025.914] (II) Initializing extension XFree86-DGA
252-[ 39025.914] (II) Initializing extension XFree86-DRI
xrandr
Code:
Screen 0: minimum 8 x 8, current 3840 x 1080, maximum 16384 x 16384
DVI-I-0 disconnected (normal left inverted right x axis y axis)
DVI-I-1 connected primary 1920x1080+1920+0 (normal left inverted right x axis y axis) 510mm x 287mm
1920x1080 60.00*+
1280x1024 75.02 60.02
1152x864 75.00
1024x768 75.03 60.00
800x600 75.00 60.32
640x480 75.00 59.94
DP-0 disconnected (normal left inverted right x axis y axis)
DVI-D-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 510mm x 287mm
1920x1080 60.00*+
1280x1024 75.02 60.02
1152x864 75.00
1024x768 75.03 60.00
800x600 75.00 60.32
640x480 75.00 59.94
DP-1 disconnected (normal left inverted right x axis y axis)
Do you also have the issue(s) on a normal distro (not Kali)? Or - assuming you actually installed Kali Linux - have you tried a Kali Live boot, since that is how it's intended to be used?
yeaahhh.... I know. You're right. I really do need to reinstall with a proper flavor. But I'm stuck with it for at least a couple more months until I can afford another drive (and the time) to do a "controlled" transition to a proper system.
I'll give it a try though. See what happens. But seems like I would somehow have to get the nvidia driver installed on that live drive to make it relevant. If I remember right, I only get very basic single monitor support without the driver.
The thing is, it represents a win for the computer and that's driving my OCD through the roof. I really just want to learn how to FORCE it to comply LOL!
My real frustration is: what search terms do I use to find the tools/understanding I need to troubleshoot it? or even, What system am I fighting? How do I discover if it's an interaction between X11/xorg.conf and nvidia? Is it just that nvidia's driver doesn't play well with kali? Why? Can kali be modified to work?
Maybe it's more work than it's worth, but it's a learning opportunity. I am hoping to deepen my understanding of GNU/Linux in general. After finally fully escaping M$, I want to dig in and learn GNU/Linux because this feel like sitting down at my TRS-80 and plugging in x/y coordinates to generate various color lines on the TV . It feels fun, and hopeful.
It's also an opportunity to become part of a forum community (which I've never done before) where I can learn and hopefully become a useful participant
Well, the quickest way to find something you say you can't find is to announce to everyone you can't find it
I guess I've been putting in the wrong search terms....for months.
I went through the process it lays out. I'm not any closer to solving this problem other than maybe the GTX 690 is just too old?
Everything seems to be good, except there seem to be a lot of N/As reported by nvidia-smi. Something isn't configured right. Seems the system isn't able to talk to the card very well. nvidia-smi -i 0 -q
Code:
==============NVSMI LOG==============
Timestamp : Tue May 3 10:34:33 2022
Driver Version : 470.103.01
CUDA Version : 11.4
Attached GPUs : 2
GPU 00000000:04:00.0
Product Name : NVIDIA GeForce GTX 690
Product Brand : GeForce
Display Mode : N/A
Display Active : N/A
Persistence Mode : Disabled
MIG Mode
Current : N/A
Pending : N/A
Accounting Mode : N/A
Accounting Mode Buffer Size : N/A
Driver Model
Current : N/A
Pending : N/A
Serial Number : N/A
GPU UUID : GPU-b049f149-4083-4292-b609-fdcbc43a5d12
Minor Number : 0
VBIOS Version : 80.04.1E.00.13
MultiGPU Board : N/A
Board ID : N/A
GPU Part Number : N/A
Module ID : 0
And in hashcat (not sure how relevant hashcat is to my issue but..)there is a lot of complaining about outdated and not supported devices. hashcat -b | uniq
Code:
hashcat (v6.2.5) starting in benchmark mode
Benchmarking uses hand-optimized kernel code by default.
You can use it in your cracking session by setting the -O option.
Note: Using optimized kernel code limits the maximum supported password length.
To disable the optimized kernel code in benchmark mode, use the -w option.
* Device #1: This hardware has outdated CUDA compute capability (3.0).
For modern OpenCL performance, upgrade to hardware that supports
CUDA compute capability version 5.0 (Maxwell) or higher.
* Device #1: WARNING! Kernel exec timeout is not disabled.
This may cause "CL_OUT_OF_RESOURCES" or related errors.
To disable the timeout, see: https://hashcat.net/q/timeoutpatch
* Device #2: This hardware has outdated CUDA compute capability (3.0).
For modern OpenCL performance, upgrade to hardware that supports
CUDA compute capability version 5.0 (Maxwell) or higher.
* Device #2: WARNING! Kernel exec timeout is not disabled.
This may cause "CL_OUT_OF_RESOURCES" or related errors.
To disable the timeout, see: https://hashcat.net/q/timeoutpatch
* Device #3: This hardware has outdated CUDA compute capability (3.0).
For modern OpenCL performance, upgrade to hardware that supports
CUDA compute capability version 5.0 (Maxwell) or higher.
* Device #3: WARNING! Kernel exec timeout is not disabled.
This may cause "CL_OUT_OF_RESOURCES" or related errors.
To disable the timeout, see: https://hashcat.net/q/timeoutpatch
* Device #4: This hardware has outdated CUDA compute capability (3.0).
For modern OpenCL performance, upgrade to hardware that supports
CUDA compute capability version 5.0 (Maxwell) or higher.
* Device #4: WARNING! Kernel exec timeout is not disabled.
This may cause "CL_OUT_OF_RESOURCES" or related errors.
To disable the timeout, see: https://hashcat.net/q/timeoutpatch
nvmlDeviceGetCurrPcieLinkWidth(): Not Supported
nvmlDeviceGetClockInfo(): Not Supported
nvmlDeviceGetClockInfo(): Not Supported
nvmlDeviceGetTemperatureThreshold(): Not Supported
nvmlDeviceGetTemperatureThreshold(): Not Supported
nvmlDeviceGetUtilizationRates(): Not Supported
nvmlDeviceGetCurrPcieLinkWidth(): Not Supported
nvmlDeviceGetClockInfo(): Not Supported
nvmlDeviceGetClockInfo(): Not Supported
nvmlDeviceGetTemperatureThreshold(): Not Supported
nvmlDeviceGetTemperatureThreshold(): Not Supported
nvmlDeviceGetUtilizationRates(): Not Supported
CUDA API (CUDA 11.4)
====================
* Device #1: NVIDIA GeForce GTX 690, 1320/1999 MB, 8MCU
* Device #2: NVIDIA GeForce GTX 690, 1952/2000 MB, 8MCU
OpenCL API (OpenCL 3.0 CUDA 11.4.189) - Platform #1 [NVIDIA Corporation]
========================================================================
* Device #3: NVIDIA GeForce GTX 690, skipped
* Device #4: NVIDIA GeForce GTX 690, skipped
OpenCL API (OpenCL 2.0 pocl 1.8 Linux, None+Asserts, RELOC, LLVM 11.1.0, SLEEF, DISTRO, POCL_DEBUG) - Platform #2 [The pocl project]
=====================================================================================================================================
* Device #5: pthread-Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz, skipped
Benchmark relevant options:
===========================
* --optimized-kernel-enable
-------------------
* Hash-Mode 0 (MD5)
-------------------
nvrtcCompileProgram(): NVRTC_ERROR_INVALID_OPTION
* Device #1: Kernel /usr/share/hashcat/OpenCL/shared.cl build failed.
* Device #1: Kernel /usr/share/hashcat/OpenCL/shared.cl build failed.
nvrtc: error: invalid value for --gpu-architecture (-arch)
Started: Tue May 3 10:42:36 2022
Stopped: Tue May 3 10:42:37 2022
Well, I think that's all down a wrong rabbit hole and has absolutely nothing to do with my ghost screen problem.
But for completeness since I posted the errors...
To fix the hashcat error: nvrtcCompileProgram(): NVRTC_ERROR_INVALID_OPTION
do: sudo apt remove libnvrtc*
after that, 'hashcat -b|uniq' runs just fine. Not that I know what that's even for lol.
@ondoho,
I made a kali live USB to try. Nouveau is the driver installed on that. I don't have any of the problems I had while running off the live usb.
I tried to install the nvidia driver by setting up the USB for persistence. I updated and fully upgraded the OS and that held through a reboot. I then installed the nvidia-driver and nvidia-cuda-tools and rebooted. After the reboot I could not get the GUI to start. Only had access to TTY.
So, yes, it works fine direct from live drive using the open source driver.
I made a kali live USB to try. Nouveau is the driver installed on that. I don't have any of the problems I had while running off the live usb.
I tried to install the nvidia driver by setting up the USB for persistence. I updated and fully upgraded the OS and that held through a reboot. I then installed the nvidia-driver and nvidia-cuda-tools and rebooted. After the reboot I could not get the GUI to start. Only had access to TTY.
So, yes, it works fine direct from live drive using the open source driver.
I wonder if nouveau got deactivated succesfully, and if Xorg recognizes the new driver.
Kali uses Xorg, yes?
I'm not any closer to solving this problem other than maybe the GTX 690 is just too old?
It might be too old for NVidia's proprietary drivers, but not for pure FOSS. The following layout is the result of pure FOSS automagic, producing no ghost 640x480 anything, and with no /etc/X11/xorg.conf. Note the loaded X driver is the (default) modesetting, not the old-technology, reverse-engineered nouveau:
Kali is just another customized Debian, so should not behave any differently using FOSS than Debian Testing (Bookworm).
For any who wonder, pinxi is the devel version of inxi, which I get from upstream.
I'm guessing what OP actually wants is a single Xorg "Screen", with 'Option "Xinerama" "1"', and the 640x480 is due to two screens in 'Section "ServerLayout"' in xorg.conf, and a second 'Section "Device"' pointing to a separate GPU. I speculate the second actual GPU is not supposed to constitute a discrete device, but rather share the job of the first.
I believe so. Do you mean as opposed to Wayland? if so, then yes it's definitely X. But if you are wondering if kali pays attention to the xorg.conf..IDK. xorg.conf does not show the 640x480 screen, but xorg.0.log shows it and inxi shows it.
I also was wondering if maybe something of the nouveau didn't completely get removed. But I have no idea how to figure if that's the case.
They have an article on NVIDIA in their docs, but Kali of course likes to use NVIDIA's CUDA stuff for computing things, and the article focuses on that. And I can't really help you with that, sorry.
I'm not sure nouveau can help with that at all, I think it's only a display driver.
That said what you describe sounds weird and unusual, but isn't observed by other users. You already troubleshot the issue to some extent and afaics it all points to this: do not use Kali as a daily driver. A mantra we have been repeating ad nauseum.
my ls -1 /sys.../drm doesn't show the ports attached like yours does.
>>"I'm guessing what OP actually wants is a single Xorg "Screen", with 'Option "Xinerama" "1"'"
I hoping to have 2 screens of 1920x1080. I don't really want to have one continuous screen where the applications full screen across both. If I'm correct in my thinking of that's what xinerama does.
But it's working fine that there is one "screen" at 3840x1080 with 1920 sections split to each monitor.
I suspect the same, that GPU1 is support to GPU0. But it seem like when I had MSwin7 I could dedicate a GPU per monitor.
I think the real question is where do I tell it to forget about the 640x480 screen? It's not in xorg.conf. I think it is coming from the nvidia but I don't know where it's set. The GUI window for nvidia is titled "NVIDIA Server Settings", but it's really just displaying what it has decided is going to happen, save a couple minor decisions it allows the user to make.
Yeah, I didn't mean to use kali as my main system. I installed it on a secondary drive to play with and ended up learning to configure and troubleshoot linux and get things working. At some point I noticed that I had forgotten about and never booted windoze.
>>"That said what you describe sounds weird and unusual, but isn't observed by other users. "
Yeah, that's me. I 'm good at finding weird issues no one else has. And also why I am interested in fixing it, because I'm sure know how to will prove useful later in any flavor. But not all problems are fixable and that's ok. I'm enjoying the rabbit holes. soooo may rabbit holes. Learning a lot.
mrmazda said:
>>"Kali is just another customized Debian, so should not behave any differently using FOSS than Debian Testing"
This is kinda why I kept with it after it became obvious I had fully switched to GNU, but I also understand the mantra. It wasn't meant at all for desktop. That said, kali has actually been pretty solid. Not much I have not been able to get sorted out. Other than this screen issue.
So, what do you mean by "using FOSS"? How would I go about using some FOSS solution, and not use neuvou? Because neveau just installed itself automatically.
.. gave up on the neuvou spelling, there. can't ever remember.
Nouveau kernel device driver is FOSS. It is required for KMS to function with NVidia GPUs, and for FOSS DDX and FOSS DIX display drivers for NVidia GPUs to function.
Nouveau reverse-engineered, old technology DDX display driver is FOSS. It is provided by an optional package that most installers include by default.
Modesetting newer technology DIX display driver is FOSS. It is provided by a the Xorg server package, so not optional, though its use with NVidia GPUs is optional, with the nouveau DDX as the KMS-supported alternate.
Using a FOSS solution means not using proprietary software, such as NVidia's drivers.
Thanks for the driver primer. That helped a lot with the acronyms.
Should I just 'apt remove nvidia-driver' and reboot and modesetting driver will 'magically' appear? Or should I somehow tell it to use the modesetting driver?
On the manjaro site I found: "The modesetting driver comes with Xorg. Just uninstall xf86-video-intel."
So it would seem that, for my situation, it would be just uninstall nvidia?
Thanks for the driver primer. That helped a lot with the acronyms.
Should I just 'apt remove nvidia-driver' and reboot and modesetting driver will 'magically' appear? Or should I somehow tell it to use the modesetting driver?
On the manjaro site I found: "The modesetting driver comes with Xorg. Just uninstall xf86-video-intel."
So it would seem that, for my situation, it would be just uninstall nvidia?
Removing NVidia's drivers is often less simple than that. With the installation package should have come removal instructions along with the installation instructions. Following them is the correct way forward.
Once NVidia's drivers have been purged, the nouveau DDX will probably be used automatically, unless its package (upstream name is xf86-video-nouveau) is not installed. The modesetting DIX can be explicitly selected via /etc/X11/xorg.conf.d/ in any .conf file of your choosing, e.g.15-dix.conf, containing:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
. It feels fun, and hopeful. 
