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