| 09:51 | MikeSeth | rabeeh |
| 09:52 | MikeSeth | 14:24 I think I just figured out how to quadruple your sales |
| 09:52 | MikeSeth | 14:24 http://tinyurl.com/macmtqb |
| 15:04 | rabeeh | MikeSeth: here |
| 15:53 | MikeSeth | rabeeh: http://tinyurl.com/macmtqb |
| 15:53 | rabeeh | i'v seen it |
| 15:54 | rabeeh | what would you do with it? |
| 15:54 | MikeSeth | uh |
| 15:54 | MikeSeth | you don't know what that is do you? :) |
| 15:54 | rabeeh | hmm... carton shaped that can be assembled into a cube |
| 15:54 | rabeeh | ? |
| 15:54 | MikeSeth | yes, but it's not just some cube, it's the Companion Cube |
| 15:54 | MikeSeth | you haven't played Portal |
| 15:54 | rabeeh | nop :( |
| 15:54 | MikeSeth | well |
| 15:55 | rabee | 15:55 * rabeeh is looking it up |
| 15:55 | MikeSeth | if you did you'd know that it's the most loved thing on the internet |
| 15:55 | _rmk_ | really? |
| 15:55 | MikeSeth | well unless you are a heathen |
| 15:55 | MikeSeth | a traitor to all that makes us human, so to say |
| 15:55 | MikeSeth | ...just play Portal :P |
| 15:56 | rabeeh | hehe |
| 15:57 | MikeSeth | bottom line is, this is an icon known to every person who has ever played a computer game |
| 15:57 | MikeSeth | you should seriously consider the marketing potential in this |
| 15:57 | _rmk_ | rubbish |
| 15:57 | rabeeh | haha |
| 15:57 | rabeeh | MikeSeth |
| 15:57 | MikeSeth | if you don't i'll start reselling your cubes in plush companion cube covers |
| 15:57 | rabeeh | i like the design; it can be fantastic to ship CuBox in |
| 15:58 | _rmk_ | now, if you said "modern computer game" I might agree with you |
| 15:58 | rabee | 15:58 * rabeeh played c&c |
| 15:58 | MikeSeth | well I didn't mean the original pong |
| 15:59 | rabee | 15:59 * rabeeh played c&c and then has two daughters and zero time to spend on computer gaming |
| 15:59 | wumpus | excellent idea, but could be hard to get permission to use that design |
| 15:59 | _rmk_ | I've not played a computer game for the last 23 years or so :) |
| 15:59 | rabeeh | _rmk_: oh you should try those strategy games |
| 16:00 | MikeSeth | "The popularity of the game and of its characters has led Valve to develop merchandise for Portal made available through its online Steam store. Some of the more popular items were the Weighted Companion Cube plush toys and fuzzy dice.[54] When first released, both were sold out in under 24 hours.[55] Other products available through the Valve store include t-shirts and Aperture Science coffee mugs and parking stickers, and merchandise relating to the ph |
| 16:00 | rabeeh | i'm not a 3d gamer and high end gaming; but strategy games like c&c, starcaft and warcraft are simply amazing |
| 16:00 | MikeSeth | I'm just saying :P |
| 16:00 | wumpus | testing GL drivers is a good excuse to play a game once in a while :-) |
| 16:00 | _rmk_ | seriously, I think the last computer game I played was a 'type it in' from the BBC Micro User magazine :) |
| 16:01 | rabeeh | wumpus: for me GL is accelerated X and accelerated xbmc menu |
| 16:01 | rabeeh | :) |
| 16:03 | wumpus | then again, those are usually old games that have been open sourced |
| 16:03 | wumpus | rabeeh: sure, but games exercise a larger part of the API generally :) |
| 16:03 | MikeSeth | how's wine on ARM? |
| 16:03 | MikeSeth | though that prolly wont help much.. would it |
| 16:03 | wumpus | wine on ARM? is that even possible? |
| 16:04 | rabeeh | MikeSeth: there is some kind of port; but i bet it's a 5MHz Pentium-1 equivalent\ |
| 16:04 | MikeSeth | apparently |
| 16:04 | MikeSeth | but not for windows x64 binaries |
| 16:04 | rabeeh | wumpus: there was some project of wine + qemu |
| 16:04 | rabeeh | i'v seen some one running something on the chromebook |
| 16:04 | wumpus | ah, for windows mobile applications, of course |
| 16:05 | rabeeh | no; windws x86 / x64 binaries |
| 16:05 | MikeSeth | http://i1.kym-cdn.com/photos/images/original/000/357/890/107.png FYI :P |
| 16:05 | wumpus | hard to believe, but ok |
| 16:06 | MikeSeth | I'm almost whoring for valve here :| |
| 16:08 | rabeeh | wumpus: http://wiki.winehq.org/ARM |
| 16:10 | wumpus | rabeeh: yep they've done it, wow, though I have a hard time thinking of how it can be useful in practice :) |
| 16:11 | rabeeh | wumpus: yeah; 1mhz equivalent |
| 16:11 | rabeeh | or maybe 10mhz |
| 16:11 | rabeeh | regardless; nice project |
| 16:12 | MikeSeth | yo dawg I herd you like emulators.. |
| 16:12 | MikeSeth | btw rabeeh how much for a dev board |
| 16:12 | MikeSeth | I want something to play with |
| 16:13 | rabeeh | you mean money? |
| 16:13 | MikeSeth | yeah |
| 16:14 | rabeeh | it's for free |
| 16:14 | rabeeh | for developers that can handle early baby steps of a new machine |
| 16:14 | rabeeh | if you feel you can contribute please send me an email to [email protected] |
| 16:15 | MikeSeth | is there specific stuff that needs to be done? |
| 16:16 | MikeSeth | I havent worked with ARM before and it's been years since I did PDP & x86 assembler |
| 16:22 | rabeeh | MikeSeth: u-boot and kernel is well staffed i think |
| 16:22 | rabeeh | xbmc is well staffed too |
| 16:22 | rabeeh | we are trying to cover round #2; which is distro contributor |
| 16:22 | rabeeh | then round #3 is application porters |
| 16:23 | rabeeh | that's looking in general and high level |
| 16:23 | MikeSeth | distro contributors as in package management? |
| 16:23 | wolfy | speaking of which: are the packages from debian or ubuntu arm7 usable as such ? |
| 16:23 | rabeeh | more into 'apt-get' on a PC; scripted to make an accelerated X ubuntu |
| 16:23 | _rmk_ | rabeeh: btw, I have output on HDMI having configured the LVDS outputs... ok, colours are all wrong. hopefully we'll see a HDMI output module for imx-drm soon |
| 16:24 | rabeeh | _rmk_: LVDS? |
| 16:24 | MikeSeth | rabeeh: so set up a crosscompile chain to produce on PC host .deb packages for the arm target? |
| 16:24 | rabeeh | MikeSeth / wolfy : the processor is armv7 + hardware floating point + neon |
| 16:25 | rabeeh | all binaries from the packages can be used as-is without rebuild |
| 16:25 | wolfy | rabeeh: so everything that runs on beagleboard black should run. excellent |
| 16:25 | rabeeh | even armv5 binaries can be used |
| 16:25 | rabeeh | wolfy: yes. |
| 16:25 | _rmk_ | wolfy: I just picked the fs I had on my cubox and dumped it on a nfs share, and setup the carrier1 to boot from that |
| 16:26 | wolfy | I've done some testing on BBB last week, now I need to persuade the account to invest in cubox-i |
| 16:26 | rabeeh | but if you have old binaries with the crippled fpa floating point then no - it won't run |
| 16:26 | wolfy | *accountant |
| 16:26 | MikeSeth | rabeeh: any link/wiki entry/work plan with a more in-depth list of goals? |
| 16:26 | rabeeh | invest? |
| 16:26 | rabeeh | want a board for free dude? :) |
| 16:26 | _rmk_ | rabeeh: err, yes it will, if you have nwfpe enabled :) |
| 16:26 | wolfy | rabeeh: i want to buy at least 5 |
| 16:27 | rabeeh | _rmk_: oh |
| 16:27 | rabeeh | isn't that you work? |
| 16:27 | rabeeh | or nico's? |
| 16:27 | wolfy | but I would not object at a free one :) |
| 16:27 | _rmk_ | and OABI compat enabled too |
| 16:28 | _rmk_ | the FPA instructions have always trapped to software emulation |
| 16:28 | rabeeh | MikeSeth: we need to have an objectives list on the wiki |
| 16:28 | _rmk_ | there's only one ARM CPU with hard FPA and that's CLPS7500, which was used in a set top box |
| 16:28 | _rmk_ | and an add-on chip for the ARM2/3 CPUs |
| 16:29 | _rmk_ | what nico did was a pure softfp version, which basically didn't use any FPA instructions - that was before EABI came along |
| 16:29 | _rmk_ | which used the FPA ordering of doubles |
| 16:31 | _rmk_ | but.. really you don't want to run OABI on ARMv6+ :) |
| 16:31 | dv | 16:31 * dv_ can finally continue hacking this evening |
| 16:31 | _rmk_ | it does work but EABI is just a much better option |
| 16:33 | MikeSeth | rabeeh: but generally the goal is to set up a debian repo specific for cubox hardware? |
| 16:35 | wolfy | MikeSeth: as i see it, it's not needed. debian's repo should work as is. it works on bbb out of the box |
| 16:35 | wolfy | rabeeh: am i right ? |
| 16:35 | MikeSeth | wolfy: then I misunderstand what's being said here wrt round 2 distro contribution |
| 16:36 | wolf | 16:36 * wolfy stops talking and goes back to learning |
| 17:02 | rabeeh | MikeSeth: the binaries of the packages can be used as is |
| 17:02 | rabeeh | but when building a distro out of repo; things cracks |
| 17:02 | rabeeh | for instance; if you want to build an ubuntu desktop version out of repo; you need at the final stage to do something like 'apt-get ubuntu-desktop' |
| 17:03 | rabeeh | but there are lots of hands to twist on the way until you get there |
| 17:03 | rabeeh | look at this for instance - |
| 17:03 | rabeeh | https://github.com/rabeeh/cubox-installer-scripts/blob/master/install-ubuntu-13.04-from-repo.sh |
| 17:03 | rabeeh | this script install ubuntu 13.04 from repo (part of the CuBox installer) |
| 17:21 | jnettlet | wumpus, rabeeh, wine on arm is not very good. OLPC had to test it for some deployments trying to get this learning software that had been developed for them under Windows working on the XO 1.75. |
| 17:21 | jnettlet | It was a hack on a hack on a hack that didn't really work too well. It was far easier to just port the simple apps over to HTML5 |
| 17:23 | dv_ | no wonder. you have to emulate x86 too then |
| 17:26 | jnettlet | dv_, did you get a chance to test that patch for DVI resolutions? |
| 17:26 | dv_ | not yet |
| 17:26 | jnettle | 17:26 * jnettlet should just dig out his hdmi to dvi and test |
| 17:26 | dv_ | does it just move the limit upwards (to something like 1024x768), or does it really remove the restriction? |
| 17:27 | dv_ | also, this is the boundarydevices kernel. isnt this the one rabeeh forked? |
| 17:27 | dv_ | or perhaps a later commit reverted this change |
| 17:28 | jnettlet | dv_, the problem is that the current fb driver is just matching the edid modes against CEA hdmi modes. It needs to see that the DVI_ENABLE bit is set and actually match against VESA modes. |
| 17:28 | jnettlet | their hack just removes the check against CEA modes and accepts anything the EDID offers up. |
| 17:29 | dv_ | so the VESA mode check is just missing? |
| 17:29 | dv_ | sounds like a useful patch |
| 17:29 | dv_ | +VESA +DVI_ENABLE check |
| 17:30 | jnettlet | dv_, and a VESA modes table needs to be added to the driver, or switch the driver over to use the fbdev hdmi framework. |
| 17:34 | _rmk_ | but does fbdev support hotplug yet? |
| 17:34 | _rmk_ | I've just prodded Shawn Guo over the imx-drm stuff |
| 17:35 | _rmk_ | and whether there's a hdmi output driver for it yet |
| 17:36 | jnettlet | _rmk_, I just checked freescale's 3.10.9 alpha kernel and there is no hdmi output driver yet. |
| 17:41 | MikeSeth | rabeeh: package management and distro release management I can do |
| 17:42 | MikeSeth | I upgraded a remote box from redhat to debian once, using only rsync and strong words |
| 17:43 | MikeSeth | btw if you have 'official' cubox distro, stuff could be managed on a higher logical level, with puppet etc |
| 17:43 | jnettlet | _rmk_, fbdev's hotplug is the same. You connect a hotplug detection handler to the HDMI hpd gpio. The interrupt kicks off a timer with a work queue so you can detect jitter and not run your connect/disconnect routines a bunch of times when plugging and unpluggin ghte cable. |
| 17:44 | _rmk_ | and the X side? |
| 17:45 | jnettlet | _rmk_, inotify on a sysfs file. |
| 17:47 | jnettlet | same way they get vblank interrupts to userspace |
| 17:47 | jnettlet | and solve the. Most our scanout hardware is different than our 3d hardware. |
| 17:56 | _rmk_ | which is probably unimplemented like it was in the dove xorg driver |
| 17:56 | jnettlet | oh boundary's mxc driver is using uevent's to report hdcp |
| 17:57 | jnettlet | _rmk_, I have a test version of it around somewhere. We decided to handle it at the kernel level since we wanted to minimize user control for the first release. |
| 18:12 | Semtex | hmmmm |
| 18:12 | Semtex | hiii ! |
| 18:14 | _rmk_ | Hi Semtex. Not sure whether to run far away from you or not. :) |
| 18:14 | Semtex | Has somebody managed to install nodejs on cubox's default distrib ? |
| 18:14 | Semtex | hmmmm "maybe" |
| 18:15 | Semtex | *clic* |
| 18:17 | jnettle | 18:17 * jnettlet keeps a relatively safe distance but answers. |
| 18:18 | jnettlet | Semtex, I have not run it on the default distro, but have run it. |
| 18:20 | Semtex | ok =/ |
| 18:20 | Semtex | ArchLinux ? |
| 18:20 | jnettlet | Fedora |
| 18:21 | jnettlet | what is the problem you are running into? |
| 18:21 | jnettle | 18:21 * jnettlet takes a cautious step backwards |
| 18:21 | Semtex | is there a package available on fedora ? |
| 18:21 | Semtex | I hate building stuff on linux, I wonder why it always fail with me :D |
| 18:22 | Semtex | In fact I think I've never been able to build something with make / make insrall xD |
| 18:22 | Semtex | install* |
| 18:22 | jnettlet | If you use the Fedora20 alpha image there is. |
| 18:22 | jnettlet | let me check previous releases. |
| 18:22 | jnettlet | yep Fedora 19 also has it built in the repos |
| 18:23 | jnettlet | I would go with that. |
| 18:23 | jnettle | 18:23 * jnettlet feels like he may need a shower now. |
| 18:24 | Semtex | ^^ Ok, I guess i'll have to make a new SD card with fedo |
| 18:24 | Semtex | have a nice shower |
| 18:24 | Semtex | and thank you |
| 18:24 | jnettlet | np. enjoy |
| 18:24 | Semtex | I'll be ... BACK |
| 18:25 | _rmk_ | we'll have to rename you to Arnie then |
| 18:25 | Semtex | *PRRR PRRR PRRRRRRRRR* :) |
| 18:25 | Semtex | or maybe shall I be bach ! |
| 18:25 | Semtex | see you later |
| 18:25 | _rmk_ | oh, you've got a handel on that |
| 18:26 | jnettle | 18:26 * jnettlet didn't like the tune of his reply |
| 18:26 | jnettlet | classical case of misunderstanding |
| 18:27 | _rmk_ | was it too much of a discord? |
| 18:28 | jnettlet | and now he is gone. we couldn't have orchestrated it better. |
| 18:28 | _rmk_ | at least it wasn't too explosive |
| 18:31 | jnettle | 18:31 * jnettlet has to prepare schnitzel's for dinner |
| 18:32 | _rmk_ | jnettlet: seen jcm's recent post on g+ |
| 18:32 | jnettlet | nope. /me goes to look |
| 18:33 | _rmk_ | $3,133.7 :) |
| 18:34 | jnettlet | those crazy google hackers. |
| 18:35 | jnettle | 18:35 * jnettlet knows Google has an office here in Århus, but doesn't know anyone there. |
| 18:40 | _rmk_ | ah ha, there's some HDMI patches around, and they're the ones Gregkh said "no, imx-drm has to move out of drivers/staging first" |
| 18:45 | jnettlet | _rmk_, have you come across why it is stuck in staging limbo? |
| 18:46 | jnettlet | unfortunately without hdmi support it is very limited in what it can be tested and developed on. |
| 18:47 | _rmk_ | not yet. :( |
| 18:47 | jnettlet | *grumble* |
| 18:47 | _rmk_ | I'm going to see about pulling the patches down, merging them into my tree temporarily and getting it working there. |
| 18:48 | _rmk_ | robclark may know... but don't know if he's still on channel |
| 18:48 | _rmk_ | yep, he is :) |
| 18:48 | _rmk_ | if not, it's a question for airlied |
| 18:48 | robclark | imx-drm? |
| 18:49 | robclark | not sure why it is still in staging.. probably mostly no one tried to move it out |
| 18:49 | robclar | 18:49 * robclark probably needs to go back and look at it again.. there was some funny tie in between v4l and imx-drm last I looked |
| 18:50 | _rmk_ | bah, annoyingly, patch 1 of the imx-drm hdmi stuff didn't make it through lakml :( |
| 18:50 | robclar | 18:50 * robclark doesn't remember seeing it |
| 18:51 | _rmk_ | http://thread.gmane.org/gmane.linux.drivers.driver-project.devel/41903 |
| 18:51 | _rmk_ | gregkh said NAK to it because he wants imx-drm out of drivers/staging |
| 18:52 | _rmk_ | (the annoying thing about gmane is you don't seem to be able to "download as text" from it |
| 18:52 | robclark | oh, ok.. I didn't notice it was part of that recent patchset.. I thought greg said he would take that series but asked after to not send new stuff and instead cleanup and out of staging.. |
| 18:52 | robclark | or.. hmm |
| 18:52 | robclark | maybe that was a different patchset (sent last weekend) that I'm thinking of |
| 18:53 | robclark | s/weekend/week/ |
| 18:53 | _rmk_ | Greg said: "I really don't want to accept this at all, as I'm not seeing any effort to get this out of staging and into the proper place in the drm tree, sorry." |
| 18:54 | robclar | 18:54 * robclark thinks he is getting patchsets mixed up |
| 19:15 | steev | to be fair, there hasn't been much effort to get it out of staging |
| 19:35 | _rmk_ | steev: I can quite see what happens, because I've seen stuff like this happen lots of times before |
| 19:36 | _rmk_ | once code gets into something like that, people are happy because they can then build it with the mainline kernel, and as far as they see, their job is done. |
| 19:37 | dv_ | yeah, cleanup and polish is the 90% after the first 90% |
| 19:43 | steev | this is true, still trying to get efikamx support back into the kernel, but it's slow going |
| 19:45 | _rmk | 19:45 * _rmk_ notes bits he needs are also in patch 2, which claims to be adding board support for hdmi |
| 20:11 | _rmk_ | humph |
| 20:18 | _rmk_ | robclark? |
| 20:18 | robclark | ? |
| 20:18 | _rmk_ | does this drmModeConnector structure look right to you? |
| 20:19 | _rmk_ | {connector_id = 6, encoder_id = 5, connector_type = 11, connector_type_id = 1, connection = DRM_MODE_CONNECTED, |
| 20:19 | _rmk_ | ... |
| 20:19 | _rmk_ | count_props = 2, props = 0x2a16b680, prop_values = 0x2a16b690, count_encoders = 0, encoders = 0x0} |
| 20:19 | _rmk_ | particularly the last two |
| 20:20 | robclark | no.. you are missing something.. count_encoders and encoders should have array of all possible encoders built up by driver calling some util fxn in drm.. |
| 20:20 | robclark | let me find the fxn that needs to be called.. I always forget the name |
| 20:20 | robclark | drm_mode_connector_attach_encoder() |
| 20:20 | _rmk_ | ok, so this is something else to add to the imx-drm TODO list |
| 20:21 | robclark | heh, yeah.. |
| 20:21 | robclark | probably I should look at why modetest somehow succeeds even with that missing.. |
| 20:22 | _rmk_ | it may be something specific to this hdmi driver |
| 20:22 | robclark | if it introduces a new connector, it probably just misses to attach that connector to encoder(s) |
| 20:27 | _rmk_ | lol |
| 20:27 | _rmk_ | robclark: it calls that function but... |
| 20:27 | _rmk_ | it calls it *before* drm_encoder_init has been called on the encoder |
| 20:27 | _rmk_ | so encoder->base.id is... rubbish |
| 20:29 | robclark | hmm.. I'm surprised it gets far enough to return count_encoders=0 to userspace without crashing somewhere along the way |
| 20:29 | _rmk_ | I think the only reason it surivies is because it also does: |
| 20:29 | _rmk_ | hdmi->connector.encoder = &hdmi->encoder; |
| 20:29 | robclark | oh.. well, maybe base.id == 0? |
| 20:29 | robclark | hmm.. |
| 20:29 | _rmk_ | probably was initially |
| 20:29 | robclark | seems a bit dodgy |
| 20:30 | _rmk_ | whoa - just spotted this in the build log |
| 20:30 | _rmk_ | drivers/staging/imx-drm/imx-hdmi.c:510:36: warning: array subscript is above array bounds |
| 20:30 | _rmk_ | const u16 (*csc_coeff)[3][4] = &csc_coeff_default; |
| 20:30 | _rmk_ | hdmi_writeb(hdmi, ((*csc_coeff)[0][4] >> 8), HDMI_CSC_COEF_A4_MSB); |
| 20:31 | dv_ | jnettlet: have there been any significant updates to your uboot fork? |
| 20:31 | _rmk | 20:31 * _rmk_ tries again |
| 20:31 | robclar | 20:31 * robclark likes -Werror so he actually notices when gcc catches silly mistakes for him |
| 20:32 | _rmk_ | ooh, I have output of sorts from X :) |
| 20:33 | robclark | \o/ |
| 20:34 | _rmk_ | HDMI1 connected 1280x720+0+0 (normal left inverted right x axis y axis) 698mm x 392mm |
| 20:34 | _rmk_ | 1280x720 60.0*+ 50.0 59.9 |
| 20:35 | _rmk_ | "of sorts" because it looks a little wrong |
| 20:38 | _rmk_ | its the output which is wrong, not what's in the framebuffer |
| 20:38 | robclark | wrong as in pitch mixup or something like that? |
| 20:40 | _rmk_ | the picture is basically correct (right shape/size etc). the colours are almost correct too (blues are blue, greens are green, reds are red) |
| 20:40 | _rmk_ | I think I'm going to have to photograph this, because this is just weird |
| 21:13 | jnettlet | dv_, nothing yet. I started poking at it over the weekend but got sidetracked with life. |
| 21:13 | jnettlet | dv_, something specific you are looking for, or just the boot script changes? |
| 21:14 | dv_ | just wanted to know if I should change something in the OE scripts |
| 21:14 | jnettlet | not yet, no. |
| 22:22 | _rmk_ | jnettlet: how stable is the image from your carrier1 ? |
| 22:23 | _rmk_ | look carefully at the 'd' in SolidRun |
| 22:23 | _rmk_ | in your uboot |
| 22:51 | dv_ | damnit |
| 22:51 | dv_ | that "no output over UART" problem again |
| 22:53 | dv_ | rabeeh: something must be wrong with the hardware |
| 22:53 | dv_ | I plug in the UART-TTL USB adapter, plug in the USB power, no output in minicom. I unplug both, wait a few minutes, try again, I see output. |
| 23:00 | _rmk | 23:00 * _rmk_ tries putting Rabeeh's uboot back on it |
| 23:01 | dv_ | ah hold on. it seems the hardware is picky about sd cards |
| 23:05 | dv_ | yay, got 720p output |
| 23:12 | dv_ | so ok, rabeeh, false alarm. it indeed is the sd card, which works fine with my pc, but not with the c1, and my laptop also doesnt like it |
| 23:35 | dv_ | ... now the sd card died. hey, I thought flash ram just becomes read-only . or maybe its the controller that is broken. |
| 23:56 | jnettlet | _rmk_, just back to the computer looking |
| 23:56 | _rmk_ | ok, rabeeh's kernel plus rabeeh's uboot produces a correct picture |