Should it be possible to run gnome-desktop on the TX1 instead of they unity desktop?
I flashed my device using Jetpack 2.3.1, apt upgraded everything, then installed gnome via apt install gnome-session. If I choose gdm3 for the default greeter, upon reboot I get only a flickering console. If instead I leave lightdm as the greeter and choose a gnome session, the screen blanks for a moment before dropping back to the greeter/login screen.
Any suggestions for troubleshooting, or anyone out there successfully running the Gnome desktop?
This isn’t really a lot of help, but the topic should be no different for a Jetson versus a desktop system. If you find help on the internet for other people running into the task of switching desktops, then it should apply to a Jetson as well.
One thing which sometimes happens when switching X11 software around is a possible version mismatch, or overwriting the video driver with an invalid version. Check that the following are still ok:
sha1sum -c /etc/nv_tegra_release
If those are ok, then you would still need to know that original Xorg ABI version has not been altered, and that only the desktop and greeter software have changed (the Xorg server itself has its own ABI; greeters and desktop environments are just ordinary executables and probably work on any ABI…video drivers are very specific to the ABI).
When I run “grep ABI /var/log/Xorg.0.log” I see this for R24.2.1:
[ 11.838] (II) Module ABI versions:
[ 12.003] ABI class: X.Org ANSI C Emulation, version 0.4
[ 12.005] ABI class: X.Org ANSI C Emulation, version 0.4
[ 12.772] ABI class: X.Org XInput driver, version 22.1
…so long as you don’t replace the Xorg server itself this should remain the same and be valid in combination with the nVidia video driver.
Thanks, that’s a place to start.
sha1sum -c /etc/nv_tegra_release
Everything checks out OK.
grep ABI /var/log/Xorg.0.log
My output is identical to yours.
I’m still spelunking through log files looking for other clues, but so far all I’ve found are these errors in my user’s .xsession-errors:
openConnection: connect: No such file or directory
cannot connect to brltty at :0
upstart: Failed to spawn window-stack-bridge main process: unable to execute: No such file or directory
upstart: gnome-session (GNOME) main process (10506) terminated with status 1
upstart: gnome-settings-daemon main process (10501) killed by TERM signal
upstart: logrotate main process (10356) killed by TERM signal
upstart: upstart-dbus-session-bridge main process (10421) terminated with status 1
upstart: Disconnected from notified D-Bus bus
I couldn’t tell you what is wrong from that, but it does somewhat seem like perhaps not everything required was installed. The missing directory mentioned might just be something generated by operating, but failing due to permissions, or it might be a missing package.
Keep in mind that I don’t even know what “window-stack-bridge” is, but I see that prior to R24.2 (meaning R24.1 and older) it was located in the sample rootfs at:
/usr/lib/aarch64-linux-gnu/hud/window-stack-bridge
Additionally, it was configured here:
/usr/share/upstart/sessions/window-stack-bridge.conf
On R24.2 and newer this changed. The conf file is still there, but I don’t see the executable. This may be a change related to going from Ubuntu 14.04 to Ubuntu 16.04. I’ll make a guess that whatever you did to add gnome did not correctly match versions…the gnome you added might be looking for a file from Ubuntu 14.04 which does not exist in Ubuntu 16.04.
NOTE: The location of window-stack-bridge is named within the conf file. You could edit this if you had a working window-stack-bridge in some other location, but I don’t see the location and “apt search” does not find anything.
OK, so I reconfigured to use gdm3 as the display manager, and instead of a greeter screen the display flickers for several minutes. I looked for errors in /var/log/Xorg.0.log and found something interesting:
ubuntu@tegra-ubuntu:~$ grep EE /var/log/Xorg.0.log
[ 157.866] Current Operating System: Linux tegra-ubuntu 3.10.96-tegra #1 SMP PREEMPT Wed Nov 9 19:42:57 PST 2016 aarch64
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 157.886] (EE) NVIDIA(GPU-0): Failed to initialize the NVIDIA graphics device!
[ 157.886] (EE) NVIDIA(0): Failing initialization of X screen 0
[ 157.900] (EE) Screen(s) found, but none have a usable configuration.
[ 157.900] (EE)
[ 157.900] (EE) no screens found(EE)
[ 157.900] (EE)
[ 157.900] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[ 157.900] (EE)
[ 157.912] (EE) Server terminated with error (1). Closing log file.
In case it helps, here’s the context for the error:
[ 157.885] (II) NVIDIA(0): Creating default Display subsection in Screen section
"Default Screen Section" for depth/fbbpp 24/32
[ 157.885] (==) NVIDIA(0): Depth 24, (==) framebuffer bpp 32
[ 157.885] (==) NVIDIA(0): RGB weight 888
[ 157.885] (==) NVIDIA(0): Default visual is TrueColor
[ 157.885] (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0)
[ 157.885] (**) NVIDIA(0): Option "AllowEmptyInitialConfiguration" "true"
[ 157.886] (**) NVIDIA(0): Enabling 2D acceleration
[ 157.886] (EE) NVIDIA(GPU-0): Failed to initialize the NVIDIA graphics device!
[ 157.886] (EE) NVIDIA(0): Failing initialization of X screen 0
Now why would X fail to start for gdm, but not lightdm?
Looks like it has no configuration information. What kind of cable is connecting to your monitor, including any adapters? What is the output of:
sudo -s
cat $(find /sys -name 'edid')
exit
I’m using an HDMI to DVI adapter to the monitor. Output is
00 ff ff ff ff ff ff 00 06 10 23 92 e0 92 00 02
1a 10 01 03 80 31 1f 78 2e fd 45 a3 57 4a 9e 25
13 50 54 00 00 00 d1 00 01 01 01 01 01 01 01 01
01 01 01 01 01 01 28 3c 80 a0 70 b0 23 40 30 20
36 00 ef 36 11 00 00 1a 00 00 00 ff 00 32 41 36
32 36 30 32 42 55 47 30 0a 20 00 00 00 fc 00 43
69 6e 65 6d 61 20 48 44 0a 20 20 20 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 5d
40 01 02 00 00 00 00 76 24 01 a5 00 ff ff 03 1a
1a a8 01 00 00 00 00 00 40 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5f
If you put that EDID data into this URL you can see what EDID tells about your monitor (and it also verifies EDID is working):
http://www.edidreader.com/
What I find interesting is that under “block 0” “standard display modes” there is only one listing…16:9 aspect with 1920 X-resolution (1920x1080). I don’t know if there is some limitation on available display modes in the Jetson versus the specs of this particular monitor (e.g., pixel clock, color depth, so on), but the basic resolution should be supported. That monitor seems to have very limited flexibility so far as what EDID says…perhaps manually creating your xorg.conf config would help (the learning curve to manually creating xorg.conf files, so it wouldn’t be fast or easy; when done, it may not even be a solution, but it would eliminate EDID problems as a cause).
I am speculating here, but am thinking that perhaps configuration is obtained by different means for lightdm versus gdm. So long as your gdm is intended to work with this ABI I think the nVidia video driver should be able to load (that’s the other question…whether or not this gdm is truly a match for this version of Xorg X11…where it was obtained and how it was compiled could have an impact). Although gdm3 obtained from the correct standard Ubuntu repository should work, I wonder how well tested it is with the nVidia driver (versus Nouveau).
So I don’t know of a good way to resolve your issue. One thing which is often recommended (but not necessarily easy to do) is to try multiple monitors if you have others to test with…if you have a different monitor with more modes supported and good EDID output, then you might get a better idea of whether configuration is just not liking that one mode on the original monitor. If the mode just isn’t reaching the stage which wants “screen 0” configured, then manually creating a screen config while ignoring EDID might be useful (figuring out config formats would take time).
If you do want to learn about xorg.conf config file formats there is a lot of material available on the web. For creating a modeline, see this:
gtf (an application)
http://arachnoid.com/modelines/
https://en.wikipedia.org/wiki/XFree86_Modeline
Useful if EDID is parsable (and can be converted into xorg.conf sections):
# (package "read-edid", related package "edid-decode")
sudo get-edid | parse-edid
sudo get-edid | edid-decode