[07:37] <janrinze> hi all, are there people here who have Ubuntu 12.04 installed on a Transformer TF101?  i have some questions about powersave and suspend modes
[07:38] <janrinze> lilstevie: hi, is there any new work done on suspend/resume for the TF101?
[07:38] <lilstevie> at the moment? no, I have been busy with uni
[07:39] <janrinze> ah. ok
[07:40] <janrinze> lilstevie: on Ubuntu 12.04 the screen saver kicks in quite swiftly but after that login is not really possible anymore due to looping..
[07:41] <lilstevie> well then change the settings :)
[07:41] <janrinze> true..
[07:42] <lilstevie> tell it not to sleep
[07:42] <janrinze> even with that it appears to go to sleep anyway..
[07:42] <lilstevie> the up-to-date tree reboots on sleep
[07:42] <lilstevie> wait, are you meaning how on power on it loops
[07:42] <janrinze> there is no apm deamon running
[07:43] <lilstevie> cause that is pulseaudio crashing lightdm
[07:43] <lilstevie> if not, the display turning off looks like sleep
[07:43] <janrinze> lilstevie: i am loged in over shh too and that works. however it will drop into powersave afer a few seconds again
[07:44] <lilstevie> on initial boot yes?
[07:44] <lilstevie> like you haven't logged in yet
[07:44] <janrinze> the ssh becomes a bit slow to respond and the screen flips on after i type something in ssh :-)
[07:44] <lilstevie> sudo apt-get autoremove pulseaudio
[07:44] <janrinze> lilstevie: the pulseaudio is removed already, that was quite a challenge with the login issues :-)
[07:45] <lilstevie> ok, disable sleep
[07:45] <lilstevie> and it won't go to sleep
[07:45] <lilstevie> make sure you tell it to never sleep for both on battery and on ac
[07:46] <janrinze> having trouble to do anything at all on the desktop since it keeps cycling..
[07:47] <janrinze> after a reboot all is fine. But once a sleep was initiated it will cycle again
[07:47] <lilstevie> yes, so do it before it goes to sleep
[07:48] <janrinze> :-) true again
[07:48] <lilstevie> I only turn the screen off on my device
[07:49] <lilstevie> sleep is turned off entirely
[07:49] <janrinze> do you know of other people working on the kernel for the TF101?
[07:49] <lilstevie> yes, but I wouldn't trust their kernels on my device :/
[07:50] <janrinze> aha.
[07:50] <lilstevie> http://forum.xda-developers.com/showthread.php?t=1683145 welcome to try it though
[07:50] <janrinze> lilstevie: what is the best/recent kernel for the tf101?
[07:50] <lilstevie> I don't agree with certain things like overclocking to 1.6 by default though
[07:50] <janrinze> i am willing to roll my own ;-)
[07:51] <janrinze> overclocking is not my aim.. stability is
[07:51] <lilstevie> well there is https://github.com/lilstevie/linux_kernel_TF101
[07:51] <lilstevie> that is the one I have running
[07:51] <lilstevie> sleep looping is not an issue cause it will reboot :p
[07:52] <janrinze> ok. i have Linux Tegra2 2.6.36.4 #5 SMP PREEMPT Fri Nov 4 22:21:17 EST 2011 armv7l armv7l armv7l GNU/Linux
[07:52] <janrinze> that one is supplied in your OLiFE Prime package
[07:52] <lilstevie> stackprotector is a little touchy and sleep breaks it
[07:53] <janrinze> aha
[07:53] <janrinze> i have worked on kernels for many ARM devices in the past and sleep was always dodgy..
[07:53] <janrinze> so i am not surprised here ;-)
[07:54] <lilstevie> hah
[07:54] <lilstevie> sleep worked
[07:54] <janrinze> lilstevie: but loops
[07:54] <lilstevie> no
[07:55] <janrinze> oh, what changed?
[07:55] <lilstevie> I mean I had sleep working at one point
[07:55] <lilstevie> I recompiled
[07:55] <janrinze> aha
[07:55] <lilstevie> must have exhaled at the wrong time
[07:55] <janrinze> yeah, i know what you mean..
[07:55] <lilstevie> because now it will not
[07:55] <janrinze> is there stuff going upstream to main kernel?
[07:56] <janrinze> would be nice to recompile a kernel from kernel.org and run that ;-)
[07:56] <lilstevie> not likely
[07:57] <janrinze> 2.6.36.4 is good enough for what i need a.t.m. so i might take a shot at building from your git repo
[07:57] <lilstevie> heh
[07:57] <janrinze> i have a lot of ARM boards laying around but none of them are Tegra 2.
[07:57] <lilstevie> as long as it gets the device booting right
[07:57] <janrinze> yeah
[07:58] <janrinze> usually fbdev + usb is my main concern
[07:58] <lilstevie> well fbdev and usb work :p
[07:58] <janrinze> if that works (and networking of course) I can get most things working.
[07:58] <lilstevie> yeah
[07:59] <lilstevie> I can work with a little less :p
[07:59] <janrinze> did uboot get any further?
[07:59] <lilstevie> uboot is a pointless dead end :)
[07:59] <janrinze> oh. because booting from a separate SDcard would be interesting.
[08:00] <lilstevie> yeah, well we have been working on some stuff using kexecboot which has been promising
[08:00] <lilstevie> at least on the tf201
[08:00] <janrinze> is kexec not working on tf101?
[08:01] <lilstevie> well tf201 has been higher priority cause I haven't officially released anything for that one yet
[08:01] <lilstevie> :)
[08:23] <janrinze> lilstevie: have you tried kexec on the tf101?
[08:24] <janrinze> lilstevie: # CONFIG_KEXEC is not set .. from /proc/config.gz :-(
[08:37] <lilstevie> if only it were that simple :p
[08:38] <lilstevie> there is hardware that will not handle a kexec
[08:38] <lilstevie> well, more the drivers are not built for it
[08:39] <janrinze> hmm.. the tf101 specific drivers won't survive kexec.. ok
[08:39] <lilstevie> we are using a derivation of http://forum.xda-developers.com/showthread.php?t=1266827
[08:40] <lilstevie> we don't know what parts are not surviving cause it prevents the kernel being kexec'd to from booting
[08:40] <lilstevie> but that hardboot works fine
[08:41] <janrinze> if hard-boot works fine then i can kexec with args to boot from SDcard :-)
[08:41] <lilstevie> you can boot from sdcard now
[08:42] <lilstevie> you just need to edit the bootimg.cfg for the kernel image
[08:42] <janrinze> how? that was not in the wiki nor in the readme
[08:42] <janrinze> ah, but that is statically changing the pootparams
[08:42] <janrinze> bootparams are flashed with nvflash.. right?
[08:42] <lilstevie> no
[08:42] <lilstevie> with the bootimg
[08:43] <lilstevie> which can be flashed from userspace too
[08:43] <janrinze> hm.. interesting..
[08:44] <janrinze> lilstevie: dd from and to the bootimg partition i guess
[08:44] <lilstevie> no
[08:45] <janrinze> mount it?
[08:45] <lilstevie> packing into a blob and dding to the staging partition
[08:45] <lilstevie> boot partition is outside of the partition table
[08:45] <lilstevie> bootloader is responsible for flashing it
[08:46] <janrinze> the blob packer is new to me. most systems i use have u-boot so i can work with that quite well..
[08:47] <janrinze> lilstevie: which partition is the staging partition?
[08:47] <lilstevie> mmcblk0p4
[08:47] <janrinze> i have that mounted under ext3
[08:48] <janrinze> so putting the bootimg in there would suffice?
[08:48] <lilstevie> no
[08:48] <janrinze> and resetting the device of course
[08:48] <lilstevie> it shouldn't be mounted
[08:48] <lilstevie> just dd straight to it
[08:49] <janrinze> ok, will try that once i have built the kernel.
[08:50] <janrinze> lilstevie: when shutting down while in android i chose 'restore' option which now makes linux the default to boot. :-)
[08:51] <lilstevie> heh as long as you remember to clear the tag
[08:51] <lilstevie> also blobs will not flash if there is a tag in misc
[08:51] <janrinze> i also did a 'wipe' which cleaned out the other partitions and they now show up in Linux as 4 partitions
[08:53] <lilstevie> system, cache and data will always
[08:55] <janrinze> is that the misc dir in mmcblk0p7 ?
[09:01] <janrinze> lilstevie: /dev/fb1 is that a second framebuffer for hdmi output?
[09:17] <lilstevie> misc is mmcblk0p3 like the whole thing
[09:17] <lilstevie> and fb1 is the second framebuffer
[09:17] <janrinze> oh. ok :-)
[09:18] <lilstevie> doesn't always mean hdmi but in this case yes
[09:18] <lilstevie> tegra fb1 can be hooked up to a few different busses
[09:18] <janrinze> i was thinking to use that as a second monitor :-)
[09:19] <janrinze> hopefully to get it to output 1920x1080
[09:24] <lilstevie> without the tegra proprietary drivers that isn't happening :)
[09:24] <janrinze> :-(
[09:24] <janrinze> so 1280x720 should at least be possible or does it mean no hdmi at all?
[09:25] <lilstevie> no hdmi at all
[09:26] <janrinze> :( !!
[09:26] <janrinze> how do the tegra drivers (beta releases) fit in there?
[09:26] <janrinze> nvidia seems to provide some
[09:27] <lilstevie> incompatible with the kernel
[09:27] <janrinze> ok. so i would need a different kernel then. 3.x ?
[09:27] <lilstevie> you would need a kernel that works on the device
[09:28] <lilstevie> that has the interface
[09:28] <lilstevie> that one I linked to before does
[09:28] <lilstevie> but as I said I wouldn't trust it on my device
[09:28] <lilstevie> if for no reason other than it burns the cpu at 1.6GHz
[09:28] <lilstevie> (I do have other reasons though)
[09:29] <janrinze> ok. i can understand
[09:29] <janrinze> best would be then to get those sources and remove the 1.6 GHz stuff and build
[09:29] <janrinze> will look into that.
[09:47] <janrinze> lilstevie: do you know why/if XShm is supported? i get an error : X Error of failed request:  BadAccess (attempt to access private resource denied)
[09:51] <lilstevie> hm
[09:51] <lilstevie> not seen that
[09:52] <janrinze> i have a program that uses XShm, it is not from Ubuntu
[09:53] <janrinze> http://code.google.com/p/rtviewer/
[17:19] <janrinze> lilstevie: ipcs shows that the kernel is not configured for shared memory, semaphores and message queues!
[20:33] <janrinze> lilstevie: you still here?