[01:46] rsalveti: are you there? [02:42] rlameiro, Just quiet on the weekends, mostly. I don't believe there are too many hobbyists here yet. [02:42] :) [02:42] well, here I am [02:42] fiddling with it [02:42] Yep :) [02:43] on top of that the video output is shifting completely the image on the tv to the left and overscaning [02:43] ... [02:44] there is something on the ubuntu kernel/uInitrd that bypass the uboot omafbdirectives [02:44] fbcvt === ian_brasil___ is now known as ian_brasil === zyga is now known as zyga-greece [13:35] hi [13:35] ogra: Any smartbook news ? [13:38] dcordes, http://tosh-ac100.wetpaint.com/thread/4253563/kernel+boot [13:39] ogra_cmpc: good stuff [13:51] hi, we also have a channel (another one ;-) -> #ac100 [13:53] marvin24, awesome [13:54] * ogra_cmpc joins [14:24] persia, ^^^^ [14:25] marvin24_: cool [14:25] I'm excited, but don't have the attention for another channel just now. [14:25] persia, i meant the url :) [14:26] the URL looks very promising indeed. [14:26] yes [14:26] i can boot android from a local kernel [14:26] using this reciepe [14:26] Can you boot a useful operating system? [14:27] probably ... the prob is that i cant get any visible console [14:27] ah [14:27] common androidism [14:27] consoles are overrated :) [14:28] trying the tegra kernel with omap4 rootfs doesnt get me anywhere either [14:28] * ogra_cmpc just tries with a panda SD here [14:30] ogra_cmpc: check if you have framebuffer console (fbcon) enabled in your kernel ( /proc/conf.gz ) [14:30] dcordes, its off [14:30] thats the prob :) [14:30] ogra_cmpc: ok. did you also request the sources ? [14:31] no [14:31] and i didnt checl the link from the EULA for two weeks either [14:31] ac100 is a weekend project for me [14:32] so i'm very slow on it [14:32] to me all of this is a weekend project ;) === ian_brasil__ is now known as ian_brasil [17:27] persia, so i have a way to run a full ubuntu netboot session ... but no input devices work at all [17:28] s/netboot/netbook [17:51] hi all , i have connected usb to serial adapter which is detected as /dev/ttyUSB0 and then i have connected to it a straight null modem cable which i have shorted at 2 and 3 pin number but i am not able print anything in minicom or getting echo of it [22:56] ogra, Nice progress. My recommendation would be to start an image that allowed ssh so you can get in there, and then play with input-utils to see where things are wrong: sounds like issues with the HID drivers. [23:01] persia, heh, that would require xinput to work at all [23:02] the system is still chrooted [23:02] no udev, no upstart [23:03] the android system is the most minimal but its still a chrooted android [23:03] Ah, without udev, I have little advice. But working with ssh/input-utils shouldn't require xinput for a properly constructed image. [23:04] well, the touchpad works with an xorg.conf [23:04] And if input-utils can't deal with a device, the chances that xinput knows what to do are strikingly low (unless, for some reason, one is dealing with non-HID devices) [23:04] the kbd is recognized in the logfile [23:04] but doesnt hand anything through [23:04] [ 11283.000] Generic KBD: dropping event due to full queue! [23:05] thats what i see in the log [23:05] Touchpad can be fixed with some udev properties then: that's trivial. keyboard probably still requires fiddling with input-utils to make sure there is connectivity, symbol mapping, etc. [23:05] i dont need to ssh ... androids adb shell is running [23:07] If you don't need to ssh, install input-utils, and try to probe the keyboard. I've locked up a couple systems doing that with exceedingly exotic input devices, (reboot was always clean), but usually they get enough low-level information that one can make the higher levels work. Might need udev properties. Might need remapping. Might need explicit support in the HID driver, etc. [23:09] well,, no udev properties possible without udev :) [23:11] No, but it's possible to determine which properties are required :) [23:11] * persia really ought file some remapping for the Saitek Commander one of these days. [23:11] /dev/input/event0 [23:11] protocol version mismatch (expected 65537, got 65536) [23:12] thats what i get for :/# input-kbd /dev/input/event0 [23:14] same thing for input-evente [23:14] *input-events [23:14] Bother. I thought I fixed that. [23:15] well, given the million lines of " Generic KBD: dropping event due to full queue!" in the xorg log ... [23:15] that might not actually be input-utils fault [23:16] i wish we still would build the old kbd driver for x [23:16] so i had actually some alternative to try [23:16] but there is only evdev nowadays [23:17] input-utils queries the kernel directly. Nothing to do with X. It makes debugging the new X input scheme *much* easier. This is all good: don't be nostalgic: it used to take forever for those of us who cared to painstakingly map things in the kernel and then *do it all over again* in an X driver. [23:18] Try `input-kbd 0` rather than /dev/input/event0 [23:18] Also, try lsinput to make sure 0 is your keyboard :) [23:21] :/# lsinput [23:21] /dev/input/event0 [23:21] protocol version mismatch (expected 65537, got 65536) [23:21] Right. Kernel bug :) [23:21] well [23:22] [12262.640000] init: untracked pid 20189 exited [23:22] android *is* a kernel bug [23:22] Yep. [23:22] * persia decides to sort out why the W axis isn't working on this mouse another day, and goes in search of food. [23:23] yeah, i'll better finish the day :)