**** BEGIN LOGGING AT Fri Jul 27 02:59:58 2012
Jul 27 06:36:16 <BV1AL> I connected USB HUB to the OTG and it work for my keyb/mouse when I boot TI Blaze with Android ICS.
Jul 27 06:36:42 <BV1AL> But if I boot ubuntu-12.04-preinstalled-desktop-armhf-omap4 on TI Blaze, and with the same connection(USB HUB keyb/mouse)
Jul 27 06:37:01 <BV1AL> the keyb/mouse has no any response even though I can see the Ubuntu desktop on HDMI monitor
Jul 27 06:37:37 <BV1AL> what can I do to solve this problem ? so I can start to configure Ubuntu.
Jul 27 06:39:11 <scientes> BV1AL, AFAIK OTG ports are reverse ports
Jul 27 06:39:20 <scientes> so they don't work for what you want
Jul 27 06:42:07 <BV1AL> so this means I cannot run Ubuntu ? but only ICS ?
Jul 27 06:42:55 <scientes> nono
Jul 27 06:42:59 <BV1AL> because the keyboard on Blaze has no any response when I boot to Ubuntu
Jul 27 06:43:12 <scientes> BV1AL, can you login via ssh?
Jul 27 06:43:14 <BV1AL> so I need a external keyb
Jul 27 06:43:40 <BV1AL> it has no network connection even I plug the ethernet to Blaze
Jul 27 06:43:57 <scientes> then you need to log in via the serial console
Jul 27 06:44:16 <BV1AL> serial port has no any response either
Jul 27 06:45:10 <BV1AL> the monitor waiting me to select language for the system, but I can do nothing
Jul 27 06:46:02 <scientes> did you unplug and replug in the keyboard?
Jul 27 06:47:26 <BV1AL> yes I did
Jul 27 06:47:59 <scientes> did you try with no hub?
Jul 27 06:48:08 <scientes> anyways serial port is your best bet
Jul 27 06:49:11 <BV1AL> in the beginning, the serial has messages
Jul 27 06:49:43 <BV1AL> but right after "Uncompressing linux... done, booting the kernel" it has no any response
Jul 27 06:49:55 <scientes> ahh then its a bug in ubuntu
Jul 27 06:50:05 <scientes> or in the parameters you are passing to the kernel
Jul 27 06:50:20 <scientes> shoudl pass something like console=ttyS0,11520
Jul 27 06:50:52 <BV1AL> when I type printenv, it has this console=xxxx
Jul 27 06:50:59 <scientes> thats wrong
Jul 27 06:51:06 <scientes> needs to be the above
Jul 27 06:51:21 <scientes> but its "bootargs" that is the important variable
Jul 27 06:51:32 <BV1AL> no, I mean it has the console=tty(something,speed
Jul 27 06:51:33 <scientes> you have to study how it is booting before messing around
Jul 27 06:51:37 <scientes> oh
Jul 27 06:51:45 <scientes> well it might be good, and it might not
Jul 27 06:51:58 <scientes> cause it has to pass it to the kernel too
Jul 27 06:52:12 <scientes> via the bootargs variable in uboot
Jul 27 06:52:20 <BV1AL> ok I'll try later
Jul 27 06:53:19 <BV1AL> does this mean even I can login through serial port and configure, I still cannot use external keyb/mouse ?
Jul 27 06:54:44 <scientes> serial port is with an external input
Jul 27 06:54:57 <scientes> that is why serial is the universal debug port, its the simplest
Jul 27 06:56:07 <BV1AL> but if everything need to send through serial port, this mean I have to depend on another PC
Jul 27 06:57:05 <BV1AL> I wish to run Ubuntu on Blaze not debug
Jul 27 06:57:20 <scientes> of course
Jul 27 06:57:44 <scientes> but you need to run evtest to figure out what is going on with the keyboard/mouse
Jul 27 06:57:47 <scientes> and dmesg
Jul 27 06:58:11 <BV1AL> I see, thanks
Jul 27 07:06:12 <BV1AL> the OTG port under ICS can act either master/slave mode depend on the microUSB I plugin
Jul 27 07:08:42 <BV1AL> I wonder how to configure Ubuntu to let OTG port do exactly the same as ICS did ?
Jul 27 07:09:39 <BV1AL> there are some demo on Youtube that they running Ubuntu on TI Blaze, how did they setup the external keyb/mouse ?
Jul 27 07:11:54 <BV1AL> or the Ubuntu they do demo on Youtube different with the image they release for people to download ?
Jul 27 07:13:02 <scientes> you need the usb port to be in host mode
Jul 27 07:14:28 <BV1AL> I knew, so I plug in a microUSB with pin4-pin5 connected, this make it act as host
Jul 27 07:14:49 <BV1AL> and this work as expected under ICS
Jul 27 07:15:06 <scientes> well you need that serial port so you can read the kernel log
Jul 27 07:15:16 <scientes> and then start sending in patches
Jul 27 07:16:08 <scientes> when you fix it
Jul 27 07:18:08 <BV1AL> is it possible to get the Ubuntu image some people demo successfully on TI Blaze ?
Jul 27 07:18:54 <BV1AL> I think they did fixed it, otherwise hwo do they demo ?
Jul 27 07:19:16 <scientes> i know nothing about that hardware
Jul 27 07:19:21 <scientes> you have a page on the stats?
Jul 27 07:20:12 <BV1AL> http://www.omappedia.org/wiki/OMAP4_Blaze
Jul 27 07:21:13 <scientes> ooo thats pretty
Jul 27 07:23:30 <LetoThe2nd> scientes: its TI's super-expensive omap4 dev platform
Jul 27 07:24:05 <suihkulokki> fsov "super-expensive"
Jul 27 07:24:48 <LetoThe2nd> ?
Jul 27 07:26:24 <suihkulokki> if you actually are going to make an omap4 product, a blaze will be rounding error in the whole budget...
Jul 27 07:26:51 <LetoThe2nd> sure, if you are into the omap4 production market thats totally irrelevant
Jul 27 07:28:23 <LetoThe2nd> but there are those folks who want to just tinker around a bit on the omap, and compared to the panda its justified to call it expensive.
Jul 27 07:30:56 <suihkulokki> well blaze isn't targeted for tinkerers
Jul 27 07:31:33 <LetoThe2nd> i never said it was. i just called it expensive. :)
Jul 27 08:09:16 <ogra_> blaze is a dual screen elephant cellphone ... only buy it if you also have the elephant to use it :P
Jul 27 08:10:20 <phh> :)
Jul 27 08:10:44 <phh> i didn't remember it could phone
Jul 27 08:10:59 <ogra_> it has a SIM slot
Jul 27 08:11:10 <LetoThe2nd> ogra_: not a SOM slit?
Jul 27 08:11:11 <ogra_> not sure we ever had a driver ...
Jul 27 08:12:38 <phh> but yeah, the blaze is here only for people who uses omap4 to complain to TI "see, it doesn't work for you either !"
Jul 27 08:13:46 <ogra_> heh
Jul 27 08:13:47 <phh> (yup that's from experience.)
Jul 27 08:14:21 <ogra_> well, it was available before the panda at least  ... without blazes the ubuntu port would have been a release later
Jul 27 14:50:41 <ogra_> infinity, any opinion ? http://paste.ubuntu.com/1113920/
Jul 27 14:57:23 <infinity> ogra_: .d is a misleading name for that directory.
Jul 27 14:57:42 <ogra_> just /etc/flash-kernel/bootscript/ then ?
Jul 27 14:57:49 <infinity> ogra_: One expects .d directories to be full of snippets that get reconstructed.
Jul 27 14:57:59 <ogra_> k
Jul 27 14:58:11 <infinity> ogra_: Yeah, just mirroring the layout in /usr/share with bootscript/ seems sane.
Jul 27 14:58:53 <infinity> (Though, I wouldn't be against designing a .d system where one could drop in bits, it's probably overkill)
Jul 27 14:59:00 <ogra_> my next step would be to make f-k-i cp the input file from /usr/share/flash-kernel/bootscript/ and make f-k check for its existence
Jul 27 14:59:31 <infinity> Well, you just made f-k look for it.
Jul 27 14:59:58 <ogra_> and after that we should look into setting root= from f-k-i so we arent depending on initrd's
Jul 27 15:00:02 <infinity> Also, this doesn't necessarily need to be a directory in /etc at all.
Jul 27 15:00:09 <infinity> Why break past assumptions?
Jul 27 15:00:22 <infinity> Can't we just use /boot/$usname ?
Jul 27 15:00:27 <ogra_> you mean reading /boot/boot.script ?
Jul 27 15:00:32 <ogra_> no
Jul 27 15:00:46 <ogra_> $usname differs from boot.script
Jul 27 15:01:00 <ogra_> it carries the subarch name
Jul 27 15:01:05 <infinity> Ahh, so it does.  But that's fine.
Jul 27 15:01:11 <infinity> It's still where people expected it to live.
Jul 27 15:01:19 <infinity> And it's not a conffile.
Jul 27 15:01:35 <ogra_> sure, but if we abuse /boot for configs again i would like to have backwards compatibility
Jul 27 15:01:59 <infinity> *shrug*
Jul 27 15:02:00 <ogra_> f-k-i should copy it from /usr/share/flash-kernel/bootscript/ to /boot/boot.script then
Jul 27 15:02:06 <infinity> It's probably more correct to have it in /etc anyway.
Jul 27 15:02:12 <ogra_> adn f-k should respect that
Jul 27 15:02:33 <ogra_> why ? /etc is for configs or did that change
Jul 27 15:02:40 <infinity> I was just thinking about people's assumptions, not about backward compat, per se.
Jul 27 15:02:45 <ogra_> i was always shouted at for putting it into /boot
Jul 27 15:02:54 <infinity> 09:02 < infinity> It's probably more correct to have it in /etc anyway.
Jul 27 15:02:58 <infinity> ^-- I just said that. :P
Jul 27 15:03:05 <ogra_> (though i still think its the most logical place)
Jul 27 15:03:57 <infinity> Anyhow, drop the .d from that patch, and it seems sane enough to me.
Jul 27 15:04:06 <ogra_> oh. sorry, misread more as not ...
Jul 27 15:04:13 * ogra_ is melting, germany has a heatwave
Jul 27 15:04:21 <ogra_> ok
Jul 27 15:04:35 <infinity> Or maybe even just /etc/flash-kernel/$whatever
Jul 27 15:04:58 <infinity> There's nothing else being shipped in that directory, seems weird to have an empty directory just to contain another one.
Jul 27 15:05:12 <ogra_> yea, less typing ... i wasnt sure we wouldnt have other stuff in there in the future
Jul 27 15:05:31 <infinity> Even if we do, the bootscr.platform stuff is well-named.
Jul 27 15:05:37 <infinity> And it's not like you'll have 30 of them.
Jul 27 15:05:42 <infinity> Not in /etc anyway.
Jul 27 15:05:48 <ogra_> and i would like to prevent having to migrate configs around more than i have to for release upgrades
Jul 27 15:05:52 <infinity> Since you should really only have the one for the platform you're running.
Jul 27 15:06:06 <ogra_> ok, i'll cut it
Jul 27 15:35:44 <ogra_> infinity, so steve just convinced me to use /etc/default/flash-kernel and there only stote the additional cmdline options ... and them make f-k append these on boot.scr generation
Jul 27 15:36:23 <infinity> That works too.
Jul 27 15:36:29 <infinity> I'm not picky.
Jul 27 15:36:36 <ogra_> sure. just a bit more work
Jul 27 15:36:58 <infinity> Though, I thought there was a drive in Debian to deprecate /etc/default in general for wheezy+1
Jul 27 15:37:02 <ogra_> that way we have an easy place to set root= too
Jul 27 15:37:19 <ogra_> in favour of ?
Jul 27 15:37:46 <infinity> Just making it go away.  Not necessarily replacing it with anything. :P
Jul 27 15:38:03 <ogra_> heh
Jul 27 15:38:14 <ogra_> that doesnt sound well thought through
Jul 27 15:44:57 <ogra_> rsalveti, any PVR news ?
Jul 27 15:45:38 <rsalveti> ogra_: I just tested with latest compiz + precise unity and things seems to be working nicely
Jul 27 15:45:57 <ogra_> YAY, one positive thing at least
Jul 27 15:46:04 <rsalveti> there's still an annoying bug but at least it's not dumping anything at the sgx side
Jul 27 15:46:04 <ogra_> (seems compiz is still not ready)
Jul 27 15:46:20 <rsalveti> not yet, I'm using the branch people are still working on
Jul 27 15:46:28 <rsalveti> but I must say I'm quite happy with the results
Jul 27 15:46:33 <rsalveti> people are finally merging the stuff back
Jul 27 15:46:38 <rsalveti> and fixing a few other issues as well
Jul 27 15:46:55 <rsalveti> so I'll be working at getting the driver at ubuntu in a few, now that the linaro release is done
Jul 27 15:46:57 <ogra_> well, as long asd it lands in the ubuntu packages i will be happy too :)
Jul 27 15:47:17 <rsalveti> yeah, probably before feature freeze I'd say
Jul 27 15:47:20 <ogra_> but compiz is pretty closely bound to feature freeze
Jul 27 15:47:28 <ogra_> yeah
Jul 27 15:47:29 <rsalveti> yup
Jul 27 15:48:00 <infinity> Is this all still build-time selection, or have we moved on to runtime yet?
Jul 27 15:48:20 <ogra_> compiz you mean ?
Jul 27 15:48:36 <ogra_> that should be runtime since GLES is also available on some intel chips nowadays
Jul 27 15:48:38 <infinity> The GL/EGL stuff in compiz, nux, and unity.
Jul 27 15:48:51 <infinity> Yes, it *should* be runtime selected, but it wasn't in precise. :P
Jul 27 15:48:55 <infinity> Hence the question.
Jul 27 15:49:00 <ogra_> but i dont know how much the reality matches "should"  :P
Jul 27 15:49:18 <ogra_> i know it was disxcussed that way at UDS
Jul 27 15:49:53 <rsalveti> hm, not that sure if this will land (runtime selection) at quantal
Jul 27 15:50:05 <rsalveti> first thing I want to see is the code merged
Jul 27 15:50:10 <ogra_> ++
Jul 27 15:50:11 <rsalveti> and not maintaining that huge patch set anymore
Jul 27 15:50:18 <rsalveti> after that we can discuss new features ;-)
Jul 27 15:50:20 <ogra_> ++++++++ !
Jul 27 15:51:53 <infinity> Fair enough.  Just as long as runtime selection is on someone's radar.
Jul 27 15:52:14 <infinity> Right now, it matters for x86.  In the future, I bet it'll matter for some ARM platforms that decide to flip-flop back to pure GL.
Jul 27 15:52:35 <ogra_> yup
Jul 27 15:52:37 <infinity> (And we really need to sort out the QT GL/EGL thing sometime too, for similar reasons)
Jul 27 15:52:48 <rsalveti> yup
Jul 27 15:52:56 <infinity> Having that all build-time selected, and having to patch everything that links to QT is such a joke.
Jul 27 15:53:19 <rsalveti> well, someone at Qt decided it was a good idea to let applications to render GL directly
Jul 27 15:53:27 <rsalveti> while also using a GL-enabled Qt :-)
Jul 27 15:53:50 <infinity> Well, you can't really stop people from using libGL directly.
Jul 27 15:54:02 <rsalveti> which let people to do whatever they wanted
Jul 27 15:54:07 <infinity> It's a shame that QT doesn't appear to provide a rich enough API that people feel they need to do so, though.
Jul 27 15:54:20 <ogra_> sure you can.  make it a symlink tolibGLES
Jul 27 15:54:41 <rsalveti> don't know how it's not working with qt5, but I'd expect to be similar in some way
**** ENDING LOGGING AT Sat Jul 28 02:59:59 2012