by tincman » Wed Jan 20, 2016 10:31 pm
Hmmm, I had no problem with the mainline nouveau module and Xorg. What did your Xorg.0.log say when it locked up?
I did have a problem when I had tegra-drm and nouveau-drm compiled into the kernel (not modules) where my console framebuffer would not initialize (but Xorg would still start w/ the modesetting driver).
The majority of Gnurou's work that has not hit mainline yet seems to be focused on getting Tegra X1 (maxwell/gm20b) support, with some minor tweaks to gk20a clocks.
$this->bbcode_second_pass_quote('', 'I') also built
https://github.com/Gnurou/xserver...
3d acceleration works, but prints some scary messages into dmesg and is kinda crashy. For example with kwin5 switching to xrender will lock up every time.
Nice! I've been trying to compile his changes as a separate Xorg stack installed in /opt (to avoid clobbering a working system), but I have been banging my head against the wall just getting it to play nice with logind.
It's a shame to hear about it's stability. What sorts of error messages are they?
On a different front, I'm finally looking into xf86-video-nouveau code, and I'm seeing a few commits concerned about gk20a support (nothing major, mostly adding the chipset as a test case for certain branches)! xf86-video-nouveau already has DRI3/PRIME support, so hopefully it won't take too much more effort to have xf86-video-nouveau enable the gk20a gpu as a renderer provider (and then use xf86-video-modesetting with tegra-drm as a sink). If #nouveau is approachable from your experience, I think I may need to jump in there as well and get some more first hand info :]
My wifi hasn't given me trouble, but this sounds familiar, and I think I ran across this issue somewhere else (but cannot recall where, sorry :[). What are the specific dmesg errors?
With the patched upowerd from Raumzeit, I can finally modprobe bq23735-charger without upowerd segfaulting, and xfce4-power-manager properly reports the charger as a power-source (sadly, this change is not yet merged upstream....). ...however, I'm still having the problems with it I had before. The module will not autoload, and the /sys/class/power_supply entry will only appear if it's plugged in when I modprobe. If it's not plugged in, a modprobe succeeds, but dmesg complains and the enetry in /sys does not appear (and will not appear when plugged in, requiring me to rmmod, then modprobe again). These issues mean I still have to remove the "<power-supply> = ..." line in the sbs-battery entry of the device-tree to make sure that module does not sit and wait for bq24735-charger to appear.
The specific error is the same that appears in dmesg when unplugging the charger after [successfully] modprobing bq24735-charger:
$this->bbcode_second_pass_code('', '
[17506.004404] cros-ec-i2c-tunnel 7000d400.spi:cros-ec@0:i2c-tunnel: Error parsing EC i2c message -121
[17506.004421] bq24735-charger 6-0009: Failed to read manufacturer id : -121
[17506.004438] bq24735-charger: probe of 6-0009 failed with error -121
')
I'm still digging around to see why this is failing... no luck so far (other than turning up it's the ChromeOS EC setting an error-status bit in the I2C response...)
$this->bbcode_second_pass_quote('', 'E')dit: Played with the sound settings (there are so many!)
The ones that actually enable sound are "Right Speaker Mixer Right DAC", "Right Speaker Mixer Left DAC" and "Left Speaker Mixer Right DAC" and "Left Speaker Mixer Left DAC" on the GoogleNyanBig alsa mixer.
That did it!! Thanks so much! ...although sometimes the sound is reverbing weirdly. Hopefully I just need to play around with the [tons] of other settings... but I'm glad to hear SOMETHING coming out of the speakers again :D.
Edit: Never mind, the sound stuttering seems to be localized to pidgin's notifications sounds. Nothing else is having a problem :D Music in the background will even play fine while pidgin's sound will occasionally stutter, so my guess is this is an application specific issue.