| 08:42 | rabeeh | frilled: ping |
| 09:47 | frilled | rabeeh, pong |
| 09:52 | rabeeh | frilled: hey |
| 09:52 | rabeeh | what's that pixels issue? |
| 09:58 | Marmotte | rabeeh: some pixels are missing on top of the screen for me, and on top and right for frilled |
| 09:58 | rabeeh | which resolution? |
| 09:59 | Marmotte | 1920x1080-32@60 for both |
| 10:00 | frilled | [10:00:02] [20:58:31] rabeeh, ever seen the image on the console fb offset to the top right via HDMI? My consoles have like 1 pixel on the rightmost column and maybe 2 or 3 pixels on the top line shaved off. That's on 1920x1080x32@60 with alarm/xf86-video-dove 0.3.4-9 |
| 10:00 | frilled | [10:00:02] [20:58:52] how was your vacation BTW ;) |
| 10:00 | rabeeh | frilled: vacation was great :) |
| 10:01 | rabeeh | thanks. |
| 10:01 | rabeeh | which kernel is that? |
| 10:01 | frilled | Good to hear :-) |
| 10:01 | frilled | oof, lemme check the repo, I have no connection to the cubox right now |
| 10:01 | frilled | it's the current alarm v7 kernel anyway |
| 10:02 | frilled | http://archlinuxarm.org/packages?arch=&search=cubox -> 3.5.7-12 |
| 10:03 | Marmotte | I picked the first kernel and modules here : http://www.solid-run.com/phpbb/viewtopic.php?f=9&t=897 |
| 10:03 | frilled | as far as I remember X11 displays correctly, need to re-check that, though, once I get home |
| 10:03 | frilled | (VPN not currently working ;P) |
| 10:03 | Marmotte | frilled: your problem doesn't appear on X11 ? |
| 10:04 | Marmotte | I saw missing pixels under awesome wm (Debian Wheezy armhf) |
| 10:04 | frilled | Marmotte, I *think* not, but I need to re-check that. |
| 10:04 | frilled | So, no comment right now. |
| 10:04 | Marmotte | I didn't check on TTY :) |
| 10:04 | frilled | I usually don't X on that box :) |
| 10:06 | frilled | I ordered a second one, though ^_^ |
| 10:07 | Marmotte | I saw on the wiki that the Logitech K400 was tested, I have the K400r, which has more shortcuts, is it useful to add a precision ? |
| 10:08 | Marmotte | (all shortcuts works without any custom configuration :D) |
| 10:10 | Marmotte | (I didn't expect the pinch-to-zoom to work on Iceweasel so easily) |
| 12:36 | Marmotte | frilled, rabeeh: I just checked, some pixels are missing in TTY too for mee |
| 12:37 | rabeeh | Marmotte: how do you check that on tty? |
| 12:37 | rabeeh | can you draw a border ? |
| 12:37 | frilled | Uhm, the text is just cut off, easy to check ;P |
| 12:37 | frilled | top lines of characters are missing |
| 12:38 | frilled | like "h" almost looks like "n" |
| 12:38 | Marmotte | the top of the prompt is not displayed :) |
| 12:56 | dv_ | rabeeh: ping |
| 13:20 | rabeeh | dv_: i'm looking into your email now |
| 13:23 | rabeeh | dv_: just sent you the logs |
| 13:27 | dv_ | alright, I restarted a fresh build using your settings. this will take a while. |
| 13:28 | rabeeh | :) |
| 13:28 | rabeeh | a while? |
| 13:28 | rabeeh | a long while i would say :) |
| 13:29 | rabeeh | oh; more questions to all |
| 13:29 | rabeeh | i'm rewriting some scripts to install ubuntu from scratch |
| 13:29 | rabeeh | i can have a rootfs.tar.xz for users to download through the installer; or i can apt-get install from the CuBox installer |
| 13:29 | rabeeh | which one is better? |
| 13:30 | rabeeh | the second one takes longer time to execute; but you get freshest debs from the repositories |
| 13:49 | dbsx | Rabeeh: use a rootfs.tar.xz, which you update say every 6 months. Tell users they should apt-get update. |
| 13:49 | dbsx | That way you have an install that works, it may not work after the update. |
| 13:49 | rabeeh | ok. |
| 13:53 | dbsx | rabeeh, by chance you wouldn't happen to have a set of instructions for a minimal debian/awesome setup? |
| 13:56 | rabeeh | nop |
| 13:58 | rabeeh | dbsx: the good thing about installing from the web directly is that in the installer you can install base; then through a submenu in the installer you can install openbox, xfce, awesome or mpd etc... |
| 13:58 | rabeeh | or zoneminder |
| 13:58 | rabeeh | all controlled part of the CuBox installer? |
| 13:58 | dv_ | rabeeh: I noticed that apparently you did not enable parallel builds |
| 13:59 | rabeeh | oh |
| 13:59 | dv_ | i thought you have an i7? and how much RAM? |
| 13:59 | rabeeh | i7 |
| 13:59 | rabeeh | 8GB |
| 14:00 | dv_ | hmm then uncommenting BB_NUMBER_THREADS = "4" and PARALLEL_MAKE = "-j 4" should be OK |
| 14:00 | dv_ | builds happen _much_ faster then |
| 14:01 | dv_ | also, I have been using the poky tarball, not git. this difference may be significant, since the tarball is months older |
| 14:01 | dv_ | anyway, lets see what comes out. I need to leave now though. later |
| 14:02 | rabeeh | ok. i'll try switching to the tarball |
| 14:02 | rabeeh | but i'll do that tonight |
| 14:04 | Marmotte | rabeeh: for our missing pixels issue, I tested on GeeXboX, and it seems to be OK |
| 14:05 | rabeeh | yes |
| 14:05 | rabeeh | i tested on ubuntu; and i'm sort of having 1 pixel missing too |
| 14:05 | rabeeh | i'm not sure why |
| 14:05 | rabeeh | geexbox are using 3.5.7 kernel |
| 14:05 | Marmotte | on my Wheezy, I am using 3.5.7 too (http://www.solid-run.com/phpbb/viewtopic.php?f=9&t=897) |
| 14:06 | rabeeh | what is your xorg.conf? |
| 14:07 | Marmotte | Debian's default, or none if there is no xorg.conf by default, I didn't look :D |
| 14:08 | Marmotte | (I have my cubox since last Friday :P) |
| 14:08 | rabeeh | probably none |
| 14:08 | rabeeh | which means you are using 16 bpp color depth |
| 14:08 | rabeeh | where geexbox uses 32bpp |
| 14:08 | rabeeh | RGBA with alpha blending |
| 14:09 | Marmotte | I have put the video= argument on the kernel line in my uboot script |
| 14:09 | Marmotte | (without that, I didn't have any X display) |
| 14:10 | Marmotte | (I don't know if it's necessary or if I did a mistake :P) |
| 14:14 | dbsx | Rabeeh: the most common questions that I have been asked are: |
| 14:15 | dbsx | 1. why cant we just have tar.xz of the keenel of distro? |
| 14:15 | dbsx | 2. I can't get the installer to work, can you help? |
| 14:15 | dbsx | kee - ker |
| 14:16 | dbsx | and that should have been kernel and distro |
| 14:16 | Marmotte | dbsx: did you get an answer for awesome ? (I was disconnected after your question :D) |
| 14:17 | dbsx | Marmotte: no. |
| 14:17 | dbsx | 3. How do I build the video drivers for xxx? |
| 14:18 | Marmotte | I made some tests on Debian Wheezy, and I have awesome running after a clean debootstrap, then "apt-get install xinit xserver-xorg awesome", and I put "awesome" in my .xinitrc |
| 14:18 | Marmotte | (I always debootstrap with minimal profile) |
| 14:19 | dbsx | Marmotte: I have the same on jessie. I am also a minmalist |
| 14:19 | rabeeh | how big is that? |
| 14:19 | rabeeh | (in .xz) |
| 14:20 | dbsx | minimal debian is < 50M |
| 14:20 | dbsx | or was that not the question |
| 14:21 | rabeeh | i mean with awesome |
| 14:22 | rabeeh | which one would you pick between xfce4, lxde, awesome, openbox, matchbox |
| 14:22 | rabeeh | ? |
| 14:22 | rabeeh | oh; and blackbox? |
| 14:22 | rabeeh | just installed awesome on ubuntu |
| 14:22 | Marmotte | I use Xfce since 2008, and I am switching to awesome now :) |
| 14:22 | rabeeh | why? |
| 14:23 | dbsx | awesome fits a usage case, and the Lua hooks are a winner |
| 14:23 | Marmotte | too much custom bindings, Xfce becomes unappropriated for me :) |
| 14:23 | Marmotte | and I hate the mouse :) |
| 14:24 | dbsx | Rabeeh: I benchmarked Lua and Luajit on CuBox. It is pretty quick. |
| 14:25 | Marmotte | I never really used openbox, so I can't say if it's good or not ^^ |
| 14:25 | Marmotte | (LXDE is openbox based, if I remember correctly) |
| 14:26 | dbsx | xfce4 has its fans (probably the most popular of the list (guess)) |
| 14:46 | rabeeh | dbsx: the only kernel i can fully rely today is my tree 3.6.9 |
| 14:46 | rabeeh | beyond that the DT based are not complete |
| 14:46 | rabeeh | that's referring back to the 'most common questions' you previously noted |
| 14:47 | rabeeh | it's missing some patches about CEC, and Audio (which i doubt they are fully working) |
| 14:48 | rabeeh | those are mainly coming from geexbox devs |
| 14:48 | dbsx | rudi's patches? |
| 14:49 | dbsx | So I can reduce my 4 different kernel gits to one? |
| 14:49 | dbsx | Thank you. |
| 14:51 | Marmotte | rabeeh: I just made a debootstrap armhf with "--include=rsyslog,netbase,net-tools,ifupdown,isc-dhcp-client,bind9-host,openssh-server,xserver-xorg,xinit,awesome" |
| 14:51 | Marmotte | after "dpkg --configure -a" and "apt-get autoclean", du says 176 Mo |
| 14:54 | Marmotte | (for Debian Wheezy) |
| 14:59 | dbsx | Marmotte: find /usr/share/doc/ -name '*' -type f -exec rm {} \; > /dev/null 2>&1 |
| 14:59 | dbsx | find /usr/share/man/ -name '*' -type f -exec rm {} \; > /dev/null 2>&1 |
| 14:59 | dbsx | find /usr/share/doc-base/ -name '*' -type f -exec rm {} \; > /dev/null 2>&1 |
| 14:59 | dbsx | find /var/cache/apt/ -name '*' -type f -exec rm {} \; > /dev/null 2>&1 |
| 14:59 | dbsx | Will trim about 30M |
| 15:00 | Marmotte | probably :) |
| 15:00 | Marmotte | I did that for my minimal ramdisk :) |
| 15:02 | Marmotte | (a simple Debian system in a ramdisk that I load from tftp) |
| 15:02 | dbsx | cool |
| 15:03 | Marmotte | I made that first when I bought my Sheevaplug, and I reuse for the cubox :) |
| 15:03 | Marmotte | (I use debirf to build the ramdisk) |
| 15:06 | rabeeh | Marmotte: i can add debootstrap in CuBox installer |
| 15:06 | rabeeh | or you can start from a netboot image |
| 15:06 | rabeeh | (initrd netboot) |
| 15:07 | rabeeh | personally i hate initrd |
| 15:07 | rabeeh | i use initramfs since it bundles both the kernel and the filesystem. |
| 15:07 | rabeeh | actually i have an 18MB xorg + xfreerdp + kernel and other goodies for tiny thin-client |
| 15:08 | rabeeh | i'm looking now for tftp server through the internet |
| 15:08 | rabeeh | so that you don't even need the microsd |
| 15:09 | dbsx | 1. I hate netboot. I can send you a wheezy debootstrap script (tested on lots of cuboxes) |
| 15:09 | dbsx | 2. Booting uImage from flash is hard to beat. |
| 15:09 | rabeeh | dbsx, Marmotte: here is my ubuntu CuBox installer script - |
| 15:09 | rabeeh | http://pastebin.com/BB6tCaEG |
| 15:09 | rabeeh | i'm re-testing it back again. |
| 15:10 | rabeeh | the final stage would be a chroot to apt-get install xubuntu-desktop |
| 15:10 | rabeeh | dbsx: the only missing thing is that i'm using an oldie kernel from ubuntu-core (3.5.7) |
| 15:11 | rabeeh | so probably i can have my 3.6.9 kernel with a bunch of kernel modules extracted on the rootfs after installation is done. |
| 15:20 | dbsx | only comment on the script: add --overwrite to the tar |
| 15:22 | rabeeh | why? |
| 15:22 | rabeeh | i'm formatting the microsd |
| 15:22 | rabeeh | remove_all_partitions() function |
| 15:22 | rabeeh | and then |
| 15:23 | rabeeh | create_one_partition ext4 |
| 15:23 | dbsx | paranoia, and habit |
| 15:23 | rabeeh | ok. i will |
| 15:34 | dbsx | rabeeh: I have watched 20 hours of video since 20130509 GeexBox. With and without passthru audio. If nothing else rudi;s patches are stable |
| 15:34 | rabeeh | which build are you using? |
| 15:35 | dbsx | The devel of 20130509 I can look up the link if you like |
| 15:35 | rabeeh | no need |
| 15:35 | rabeeh | performance wise; CEC is enabled by default which does tons of i2c polling |
| 15:35 | rabeeh | just disable that and see how performance becomes even better |
| 15:36 | rabeeh | i'm not saying that they are buggy; i'm saying no other developer reviewed them |
| 15:36 | rabeeh | rudi has been doing great job supporting CuBox. |
| 15:38 | dbsx | Not rapt about CEC. No lags in video or audio (except for 1 junk avi). It has CPU to spare. |
| 15:38 | dbsx | Can one disable CEC without a rebuild? Do you know? |
| 15:41 | rabeeh | yes |
| 15:42 | rabeeh | setting |
| 15:42 | dbsx | ok |
| 15:42 | rabeeh | system --> input devices --> peripherals |
| 15:43 | rabeeh | are you familiar with the 'graphics scaling' too? |
| 15:43 | rabeeh | oh; yesterday i'v added rutorrent as default for every build |
| 15:43 | rabeeh | i sent a patch for that (thanks to tomlohave for including rutorrent in openbricks) |
| 15:44 | rabeeh | rutorrent is great since it searches, downloads links and easy to use web i.f. for rtorrent |
| 15:44 | rabeeh | i hooked a usb drive, configured rtorrent (via the web) to download everything to that drive |
| 15:44 | dbsx | I will test it |
| 15:59 | _rmk_ | oh my, the marvell i2c driver in mainline seems rather broken. |
| 15:59 | _rmk_ | the si clock driver uses smbus messages, which provokes this behaviour... |
| 16:00 | _rmk_ | - start, write address + write, send a byte, restart, write address + write, restart, write address + read, *bus hang* |
| 16:03 | rabeeh | i2c controller inside dove isn't something to be proud of |
| 16:03 | dbsx | gnite all |
| 16:04 | frilled | nite dbsx |
| 16:04 | rabeeh | good night dbsx |
| 16:12 | _rmk_ | rabeeh: neither is the driver |
| 16:12 | _rmk_ | its racy as fsck |
| 16:13 | _rmk_ | I've been noticing things going wrong on the cubox as I change stuff, and simply adding another printk shifts the code around enough to peturb the race |
| 16:15 | _rmk_ | that i2c driver is already crappy enough that it uses an interruptible wait, which will abort any i2c transaction initiated from a process which uses signals |
| 16:16 | rabeeh | _rmk_: there is some race condition internally that you need to usleep(1) from time to time |
| 16:16 | dv_ | ouch |
| 16:16 | dv_ | hello again btw |
| 16:16 | rabeeh | i forgot where exactly |
| 16:17 | rabeeh | that was long time ago |
| 16:17 | _rmk_ | I'm just sending a mail to Mark Greer about his driver :) |
| 16:18 | dv_ | oh _rmk_, in your opinion, does going from softfp to hardfp generally yield a significant gain? |
| 16:19 | dv_ | I have heard conflicting opinions about this one. of course there are big gains in some special cases, but I mean overall, for example when building an entire distro either with soft- or hardfp |
| 16:21 | _rmk_ | are you referring to the difference between armel and armhf? |
| 16:21 | rabeeh | _rmk_: i think he is referring to -mfloat-abi=hardfp |
| 16:22 | rabeeh | armel and armhf differs a lot (armel is armv5 and armhf is armv7; besides the floating point abi difference) |
| 16:26 | _rmk_ | the big difference between armel and armhf is how the fp arguments get passed. in armel, it is through integer registers. armhf is through the vfp registers instead. |
| 16:26 | _rmk_ | and some armv5 has vfp too so I don't buy your explanation |
| 16:27 | rabeeh | _rmk_: first Orion chips from Marvell has armv5+vfp (i worked for that team) |
| 16:27 | rabeeh | as i recall 88E5082? |
| 16:28 | rabeeh | 88f5182 |
| 16:30 | _rmk_ | okay, the marvell i2c driver is devoid of maintainer now |
| 16:30 | _rmk_ | no entry in MAINTAINERS and the address in the file doesn't work |
| 16:33 | _rmk | 16:33 * _rmk_ sends the interruptible wait patch off to the i2c maintainers |
| 16:33 | _rmk_ | ... and will continue to try and fix this race |
| 16:46 | _rmk | 16:46 * _rmk_ ponders how to fix this... having a state machine running in interrupt context, and falling back to process context for the next bit of the message is insane and actually the cause of this problem - especially because the FSM gets in front of the process context when sending the restart+address |
| 17:15 | _rmk_ | that fixed it :) |
| 17:15 | rabeeh | :) |
| 17:16 | _rmk_ | now I need to work out how to make it a little more bullet proof given this horrid FSM Mark has in here |
| 17:39 | _rmk | 17:39 * _rmk_ tries this again; I think the TDA9981 had random registers scribbled to as a result of that bug |
| 17:39 | _rmk_ | which made the colours all wrong |
| 17:39 | _rmk_ | err TDA19988 |
| 17:39 | _rmk_ | either that or I've introduced a bug |
| 18:39 | _rmk_ | fsck, I think that i2c driver crap has messed up my TDA19988 |
| 18:39 | _rmk | 18:39 * _rmk_ tries going back to the NXP driver for it |
| 18:49 | _rmk_ | hmm, that solved it. |
| 18:49 | _rmk_ | I wonder if its some register which the DRM TDA19988 driver isn't writing then |
| 19:03 | _rmk_ | well, it _does_ work :) |
| 19:04 | _rmk_ | I guess I just need to add "debug the drm tda19988 driver some more" to the list of things to look at :( |
| 19:30 | rabeeh | what is the drm tda19988 thing? |
| 19:30 | rabeeh | how it's related to drm? |
| 20:09 | _rmk_ | rabeeh: yes, it's a driver for use only by DRM based drivers, because it's implemented as a drm slave-encoder driver |
| 21:33 | _rmk_ | erm, can I ask a rather fundamental question about kirkwood-i2s.c |
| 21:33 | _rmk_ | this fundamental question is... |
| 21:33 | _rmk_ | what if your record and playback rates being asked of the driver are different? |
| 21:33 | _rmk_ | it seems to me that the last one requested gets to set the rate on the entire i2s controller |
| 21:34 | _rmk_ | (yes, I know the cubox doesn't support record tho.) |
| 21:45 | _rmk_ | oh, hang on, the capture side is only ever clocked externally |
| 21:45 | jnettlet | _rmk_, that is a bug we found in our mmp i2s controller. So it probably exists for the kirkwood also. |
| 21:47 | _rmk_ | or is it... the func spec is being totally unclear on this |
| 21:47 | jnettlet | we are currently forcing the rates at the hardware level to be the same and are letting software resample as needed. |
| 21:48 | rabeeh | jnettlet: i'm not sure if it's the same i2s controller |
| 21:49 | _rmk_ | ah yes, its the same clock, so what's it mumbling on about the record and playback rates being different and needing the dco ppm tweaked |
| 21:50 | jnettlet | rabeeh, the i2s controller is not exactly the same, however the drivers are written in a very similar manner. |
| 21:50 | _rmk_ | the LRCLK is shared for god sake, so there's utterly no way that the rates can't be different |
| 21:50 | rabeeh | _rmk_: true |
| 21:51 | rabeeh | i'm not sure about SPDIF in |
| 21:51 | _rmk_ | so yes, jnettlet, this suffers from the same problem :) |
| 21:51 | _rmk_ | it doesn't have spdif in |
| 21:51 | _rmk_ | lets try an experiment... |
| 21:52 | _rmk_ | oh, can't on the cubox because we thankfully don't advertise any capture device |
| 21:52 | _rmk_ | so this bug remains hidden |
| 21:54 | _rmk_ | jnettlet: did you push the fix upstream? |
| 21:54 | rabeeh | right |
| 21:54 | rabeeh | no spdif-in in this version |
| 21:54 | _rmk_ | jnettlet: if so, which kernel, and which file? |
| 21:54 | jnettlet | _rmk_, the fix was in a different but similar driver. |
| 21:54 | jnettlet | let me dig up the git commit |
| 21:56 | rabeeh | _rmk_: for i2s in it requires i2slrclk, i2sdi and i2sbclk signals (page 242 in the spec) |
| 21:56 | rabeeh | so the clock for i2s in comes externally; you should be needing the dco for that |
| 21:57 | jnettlet | _rmk_, hmmm. the fix that got pushed was in the codec. I guess they didn't take my fix. http://dev.laptop.org/git/olpc-kernel/commit/?h=arm-3.5&id=df89b8bd72dca70706253a2510ee9676200d64da |
| 21:57 | jnettlet | I don't have my git repos handy as everything is packed away for an impending move. |
| 21:58 | _rmk_ | I wonder how many suffer this bug actually |
| 22:07 | rabeeh | _rmk_: you are right |
| 22:07 | _rmk_ | oh, oh oh oh, I'm sooo going to have to fix that friggin tda19988 driver. |
| 22:07 | rabeeh | the spec says that too - 'The I2S input and I2S output can only operate at the same sample rate' |
| 22:07 | rabeeh | :) |
| 22:08 | _rmk_ | I can't put up with blue being pink, and orange being green :( |
| 22:08 | _rmk_ | rabeeh: yea, I'll add it to something to look at. |
| 22:08 | _rmk_ | I'm soo going to have to push out some of these fixes |
| 22:12 | jnettlet | _rmk_, don't know if you carried it over to your drm driver, but the framebuffer driver has a rbswap property to handle various LCD's |
| 22:13 | _rmk_ | jnettlet: it doesn't quite look like red/blue swap, though I can try that by tweaking the muxes on the tda19988 right now |
| 22:14 | jnettlet | _rmk_, it is a register setting on LCD_SPU_DMA_CTRL0 |
| 22:16 | _rmk_ | no, they're all swapped over |
| 22:17 | _rmk_ | after the NXP driver has touched the TDA19988, I need to program the tda19988 muxes as reg 00:20 -> 01, 00:21 -> 23, 00:22 -> 45 (each nibble controls how a 4-bit lane of the RGB88 is mapped) |
| 22:17 | _rmk_ | that's always worked before I had the "accident" with the i2c driver |
| 22:18 | _rmk_ | now, it wants after power cycling... 00:20 -> 23, 00:21 -> 45, 00:22 -> 01 |
| 22:20 | _rmk_ | (what I can't remember is which way the mapping goes, whether the data decides on the RGB888 input bits or whether the register offset does) |
| 22:22 | _rmk_ | right, each register nibble defines the input pins used |
| 22:28 | _rmk_ | ok. time to make my head explode through reading the NXP driver... |
| 22:31 | _rmk_ | *ARGH* |
| 22:32 | _rmk_ | rabeeh: so, could you please tell me definitively how the TDA19988 is connected to the Armada 510 please, particularly how VP[ABC][0:7] are connected to LCD_D[23:0] ? |
| 23:32 | _rmk_ | right, bank 00 reg 27 is the problem case |
| 23:48 | _rmk_ | and that's... another mux in the video path |
| 23:48 | _rmk_ | defaulting at power on to no translation (VIP output 23:0 maps to the next stage 23:0 on powerup) |