Hey folks, heres an interesting issue… So, I decided to go ahead and flash openSUSE 13.1 onto the TK1 I have, and it works amazing! Except… when i try to load a UI. All i get is a solid white “cursor” in the upper left corner and a non responsive system over a black screen. I’m wondering if the libglx.so file is being messed with, and/or if there is anyway to sucessfully have KDE3 (or 4), run on this without an issue. I’m not a fan of Gnome but could also use xfce IF theres a nice DM for it.
Any ideas would be great and a solution would be amazing, please let me know if anyone has any ideas, I can give you any info you need about the system setup. Thanks in advance!!
Wanted to add that I am using R21.4 , openSUSE 13.1, and every other aspect of the board including usb (with hub) seems to be working just fine, i can get on the internet, i have everything i normally would just with no working GUI. Thanks
Sadly it wants to boot right into the GUI instead of a console/terminal, which i would prefer anyway for the moment. If i can get these issues fixed, I will be good to go. Just wanted to add that as well.
Any time certain hardware access events occur in X11, the lack of a handler will crash the GUI. Back in the earliest days of Linux GUI when there was no hardware acceleration the Mesa3D libraries provided all OpenGL access. If a screen saver was chosen which used OpenGL but Mesa3D was not installed, then the moment the screen saver started the GUI would crash. The same could be said for even a mouse hover over some icons or the mouse hovering over real estate requiring handling by a missing library. In the case of Jetson, some outside libraries are incompatible “updates” of nVidia variants. Make sure you have the nVidia versions in place, not overwritten by new software additions.
It is also possible that the nVidia versions are in place, but the software the nVidia version was designed to interact with is incompatible. Specifically, this is the X11 ABI. The X server itself progresses in its binary interface and requires the nVidia software to be compiled against this ABI. So some parts of the system require nVidia files in place, and in the chain of dependencies, the nVidia files require the X11 ABI to match. Upgrading the ABI but not the nVidia files will cause failure.
For reference, this is the block of log file from “/var/log/Xorg.0.log” on Jetson TK1 which identifies ABI information for a working L4T R21.4:
[ 17.049] (II) Module ABI versions:
[ 17.049] X.Org ANSI C Emulation: 0.4
[ 17.049] X.Org Video Driver: 15.0
[ 17.049] X.Org XInput driver : 20.0
[ 17.049] X.Org Server Extension : 8.0
ABI 15 is required for the X graphics to not fail with this nVidia driver set. If one were to downgrade from a newer X11 server to this version, you would find the XInput driver ABI would also need to be downgraded…the input drivers depend on the video ABI, as do the nVidia graphics packages.
I wonder if perhaps the alternate non-L4T system you are testing uses a video driver ABI newer than 15?
So this time i tried deleting it and making a symlink over to the one located int he tegra folder, however, same thing, Black screen, and a dead cursor that doesnt even blink in the upper left corner and the system does nothing…
I just reflashed, AGAIN, and im about to try simply copying the file this time from the tegra folder to the xorg/modules/extensions folder and see if THAT might make a difference.
very frustrating, wish we could get something working here, i really would prefer KDE, but if im stuf with lightDM thats going to have to be fine as long as i have a UI i can use. cant seem to get KDE to install from the default repo’s anyway right now.
ok, so copying the file from the tegra folder into the extensions folder does no good, same thing. absolutely frustrating! There has to be a simple solution for this so I can have a GUI, it obviously CAN be done considering that the base OS that comes with the board has a GUI to it. I’m at a loss, any ideas?
What ABI is your X11 software? There should be a log from any attempt to run it, regardless of success/fail. E.g.:
awk '/Module ABI versions/,/Server Extension/' /var/log/Xorg.0.log
A TK1 running R21.4 shows:
# awk '/Module ABI versions/,/Server Extension/' /var/log/Xorg.0.log
[ 13.698] (II) Module ABI versions:
[ 13.698] X.Org ANSI C Emulation: 0.4
[ 13.698] X.Org Video Driver: 15.0
[ 13.698] X.Org XInput driver : 20.0
[ 13.698] X.Org Server Extension : 8.0
I’m especially interested in knowing if the Video Driver version is newer than 15.0. This would be a “smoking gun” as to at least one cause of failure.
I run that command, and also check in /var/log/ and its saying file not found.
this is a sad day. i would love to know what this thing is using so i know the easiest way to install. I am wondering that since i am installing the xorg-x11-server, if that is changing it and if so, if its possible to not even install that IF xorg is already loaded since there is the xorg/modules/extensions folder already in the system prior to installing that xorg-x11-server…
OK, so im currently installing ONLY the xorg-x11-server so i can see if i can get a readout on it from the command you provided above. hopefully this will show us something as to which video driver is in use and possibly find a way to modify it from there!?
ok well, we have a new lead… installing ONLY xorg-x11-server, starts xserver during boot and i get the system hang there so its NOT the GUI doing it, its Xorg itself ;) maybe that helps?
There also doesnt seem to be a way from booting without the XWindow Manager loading once the xorg-x11-server has been installed, so im having to flash everytime we try something, any ideas on a way to make it where i can get grub2 or something so i can pic text based when it fails?
This is the package available in YAST right now that i can install, but before I do, its stating that its version 10 it looks like… i could be wrong but thats what im reading…
An explanation of the involved software might help.
So far as boot loader goes, grub is not used with embedded systems. The equivalent is u-boot, which has a configuration file which isn’t all that different from early grub…but it requires the serial console to access during boot, e.g., to pick alternate boot images. If you need more information about how to work with this file, just ask.
Serial console would show all messages, even during the failure. This could be copied and pasted from your host running a serial console program such as gtkterm or minicom. The system might even be up and running just fine, other than GUI.
If you need a copy of the file system, e.g., to access files known to exist but inaccessible via the running TK1, then you can clone partitions. Cloning takes a lot of time and disk spcae. A serial cable (NULL modem cable) is much faster and easier. See: http://elinux.org/Jetson/Cloning
For terminology and organization of a GUI:
xorg-x11-server is fundamentally the graphics. The X11 server is the core of all things GUI, Xorg is a brand used for free distribution. Xorg is an X11 protocol server.
An optional display manager deals with GUI login choices, e.g., offering login to different people and optionally different flavors of desktop software...KDE, Gnome, and Lightdm are examples of desktops possibly loaded by a display manager. For KDE the display manager is kdm, for Gnome it is gdm. This doesn't matter much, they're mostly interoperable, e.g., kdm works to run gnome desktops. Once the user logs in, any display manager goes away.
The window manager is an application, not a server. All of those menus and borders and background pictures are a result of a window manager which runs on top of the X11 server, i.e., window manager runs on top of Xorg.
Some aspects of kernel interaction with the GUI can be controlled via kernel command line arguments, e.g., through the APPEND key/value pair in "/boot/extlinux/extlinux.conf"...this depends on specific kernel features and is probably not what you want.
"init" is the set of scripts which the kernel starts running right after the kernel itself is loaded. There are variants and philosophies associated with how this is organized, but the gist is that init controls what is started and when during boot. init is essentially the parent of determining how GUI support is started. Typically init starts either another program to pick GUI configuration, or else can directly start GUI options. Directly adjusting init could do what you want, but is highly unlikely to be desirable. Software started by init to read configurations is most likely what you want. Mostly this configuration is in "/etc/X11/"
init can be used to set the default boot to stop loading further GUI software and stop at the stage where everything "text" is up and running, including networking. This would allow you to manually start X11 with various options and may be what you want. On Fedora and many others the default run level (e.g., single user no net, multi-user net but no GUI, GUI) is simply a symbolic link to an init target and named "default.target". I'm not sure on Ubuntu where this is set.
Serial console is immune to runlevel, init scripts, GUI, and networking. This is the easiest way to access a system having problems with access.
So…what behavior or feature are you looking to control while figuring out how to get this alternate system setup working?
ok, so heres my goal… I will be clustering 4 TK1’s together, ( that part i have figured out already, just waiting to get this initial portion completed. )
Board 1 - the main one, I want to have a GUI on it, that is able to boot into, and use as i would a standard PC… The other 3 boards will simply be clustered to the main one for additional power. ( as has been done time and time agin in the past by others as well as done using raspberryPI clusters.)
So currently i am working to get the primary board up and running with a GUI on it. That is all i need and I will be able to move forward. I hope that explains the goal here and we can find a quick solution to get this knocked out.
As far as the GUI, i prefer KDE, i just really like it, not a huge fan of gnome, or xfce, but would use one if i simply HAD to. From this point, what can be done to get a working KDE Desktop working, so I can continue forward?
I have the nvidia_drivers.tbz2 unpacked on the TK1 right now and able to be accessed if that helps. I am going to now see if i can setup SSH from my PC ( running openSuse 13.2 ), to the TK1 (running openSUSE 13.1 )…
FYI, I myself have stuck to KDE desktop for a long long time, so I understand the desire. The Qt widgets and code is itself very portable, and exists for many ARM devices, mobile phones, so on…I would expect that anything needed for KDE to run on a Jetson is available by default for whatever distribution you run.
Is it correct that this is with an OpenSUSE install? I’m only somewhat familiar with this, but what it comes down to is that if you have any working desktop, including one you don’t want, then adding KDE gets much easier.
KDE has both the desktop environment and the display manager (KDM). You don’t need the KDM display manager, whatever is already in place should simplify life. Can you get any GUI using any desktop running? If so, I’d advise doing this, then adding KDE, and when KDE works, removing the other desktop (but not the display manager, e.g., if GDM is the display manager I’d just leave this in place…there may in fact not even be a display manager on many embedded distributions).
Are you able to access the internet and search for rpm packages which are for KDE?
yes the TK1, as well as my PC are running open SuSE. the PC is 13.2, and the TK1 is the ported 13.1 flashed and ready to go, and i am now SSH’d into the TK1 - main board - and i can work with it. I can also use YAST on the TK1 to get KDE base packages installed as well, however it obviously needs Xorg-X11-server which is what seems to be causing the hang up.
Also to answer your last question, no i cannot get ANY GUI working on this. I was hoping to at least get xfce and then install KDE and drop xfce, but that wont even work, its crazy