Hi,
My USB AVR V2 has just arrived and I am trying to get it working. I have installed the utilities but…
Running as a user, I get this message:
me@wsta1:~> /usr/local/bin/pavr2gui
Invalid MIT-MAGIC-COOKIE-1 keyqt.qpa.screen: QXcbConnection: Could not connect to display :0
Could not connect to any X display.
… and as Root, I get:
# pavr2gui
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'
qt.qpa.screen: QXcbConnection: Could not connect to display
Could not connect to any X display.
I guess it is a problem with my local setup, but I am hoping that someone here can tell me how to correct?
I am running openSuSE Leap 15 64bit, with the KDE plasma desktop.
I set up an openSUSE Leap 15 x86_64 virtual machine here and chose the KDE Plasma desktop, but I was unable to reproduce the problem you are having.
You might consider using the command-line utility, pavr2cmd, which can do everything that the GUI can do.
If you want more help troubleshooting the GUI, please run strace -o log.txt pavr2gui and then post the resulting log file here so we can see what might be going wrong.
It looks like the GUI is reading an authentication string called the “MIT-MAGIC-COOKIE-1” from ~/.Xauthority and sending it to your X server, but your X server is replying that the cookie is invalid. If you have not rebooted recently, I recommend doing that, just to see if the problem goes away on its own. If that does not work, please run the following five commands and post the output from each one here:
env | grep DISPLAY
env | grep XAUTH
ls -l ~/.Xauthority
ls -l ~/.local/share/sddm/.Xauthority
xauth info
mprowe@Gzunder:~> ls -l ~/.Xauthority
-rw------- 1 mprowe users 281 Mar 19 07:48 /home/mprowe/.Xauthority
mprowe@Gzunder:~> ls -l ~/.local/share/sddm/.Xauthority
-rw------- 1 mprowe users 52 Sep 3 2018
/home/mprowe/.local/share/sddm/.Xauthority
mprowe@Gzunder:~> xauth info
Authority file: /home/mprowe/.Xauthority
File new: no
File locked: no
Number of entries: 5
Changes honored: yes
Changes made: no
Current input: (argv):1
Thanks for the additional information. My newly installed openSUSE Leap machine is a little different from yours.
My machine uses ~/.local/share/sddm/.Xauthority, and ~/.Xauthority does not exist. However, based on the timestamps , I would say that ~/.Xauthority is the right one for you to be using, and you should continue using it.
Another difference is that I only have one entry in .Xauthority, whereas you have 5.
Please run the command below so I can see what entries you have. With this information, I might be able to reproduce the issue here.
xauth list | cut -c -45
(That command uses cut to hide most of the cookie, while still allowing me to see the first 6 digits.)
mprowe@Gzunder:~> hostname -A
gzunder.localnet
mprowe@Gzunder:~>
The first entry (shown in red), is the format used by default for my
Virtual openSuSE installations. However, none of the currently installed
VMs have that hostname.
But that is not to say, it is not a leftover from an earlier exercise?
The remaining four seem to be variants on this workstation. See
“hostname -A” above.
As I don’t know what is adding these extra entries, I’d like your advice
on how to “clean it up”? Hopefully, that will allow pavr2gui to run?
Did you compile pavr2gui from source, or are you using the pre-compiled binaries we provide in the user’s guide (and in the Resources tab of the product page)?
To clean up those extra entries, you could try renaming the .Xauthority file to something else so that the system cannot find it, and then rebooting. The X server should create a new .Xauthority file when it starts up. I do not think that will help though.
I see that your computer’s hostname is “Gzunder” with a capital “G” according to your command prompt, but its fully-qualified domain name is “gzunder.localnet” with a lower case “g”. You have xauth entries that differ from each other only by capitalization. This might be confusing some of the software that works with those cookies. Could you try configuring your computer so that the hostname uses lowercase letters everywhere? If “Gzunder” is coming from /etc/hostname, you can probably just edit that file and reboot.
However, the bad news is, it has not made things any better?
mprowe@gzunder:~> strace -o log.txt pavr2gui
No protocol specified
qt.qpa.screen: QXcbConnection: Could not connect to display :0
Could not connect to any X display.
mprowe@gzunder:~> env | grep DISPLAY
DISPLAY=:0
mprowe@gzunder:~>
The “No protocol specified” error is what I saw happen when I would change the hostname of my machine and then try to run the GUI without rebooting. After changing the hostname, you should reboot so the X server can update the .Xauthority file. Can you try that and see if anything changes?
Oh no…
I gota report some bad new. Its gone again!
Following yesterdays successful test ( I had assumed maybe you were right - I had not rebooted?), I had to finish some other work and had to leave inspecting the GUI & programmer until today.
Today (computer switched off overnight), I get the “No protocol specified”. So I run round the loop again:
Delete .Xauthority
Reboot
Run parv2gui (in a konsole, so I can see the error messages)
And no-go. I can only get the “No protocol specified”.
The only thing that has changed since last night (working) and today (not working), is the elapsed time and running the Thunderbird mail client.
Thanks for the continuing assistance. Info as requested:
mprowe@gzunder:~> pavr2gui No protocol specified qt.qpa.screen: QXcbConnection: Could not connect to display :0 Could not connect to any X display.
mprowe@gzunder:~> xauth list | cut -c -65 gzunder/unix:0 MIT-MAGIC-COOKIE-1 3ebd37592e529a56e0f2a947e12d5
mprowe@gzunder:~> hostname gzunder.localnet
mprowe@gzunder:~> hostname -f gzunder.localnet
mprowe@gzunder:~> hostname -A gzunder.localnet
mprowe@gzunder:~> cat /etc/hostname gzunder.localnet
mprowe@gzunder:~> cat /etc/hosts # # hosts This file describes a number of hostname-to-address # mappings for the TCP/IP subsystem. It is mostly # used at boot time, when no name servers are running. # On small systems, this file can be used instead of a # “named” name server. # Syntax:
**# ** # IP-Address Full-Qualified-Hostname Short-Hostname #
Could you change the contents of /etc/hostname to gzunder, then reboot and try again?
I was able to reproduce the problem here by setting by /etc/hostname to grayson.localnet, rebooting, and then running hostname -F /etc/hostname. Before I ran that final command, I saw that uname -n, hostname, and xauth list all used the same hostname, which was grayson. After I ran that command, uname -n and hostname started returning grayson.localnet, but the .Xauthority file had not been updated so there was a mismatch, just like on your system.
When this mismatch is present, pavr2gui fails with the “No protocol specified” error, probably because it cannot find any cookies in the .Xauthority file that match the hostname. Standard programs like xman and xeyes also print the same “No protocol specified” error when the mismatch is present. After printing that message, those programs try again and do something different that allows them to succeed, probably because of the patches OpenSUSE applies to libxcb.
If you run man 5 hostname to read the documentation of /etc/hostname, you can see that it recommends having “no spaces or dots”.
Yes, I have edited my /etc/hostname and yes, that has done the trick. I
have tested over several days and multiple invocations.
And as yet, no unintended consequences.
