| 00:02.11 | theborger | so what is one of the better netbooks to buy? is the samsung chromebook good? or is there one cheaper? |
| 00:17.34 | *** join/#arm-netbook vinifm (~Vinicius@187.114.119.182) |
| 00:30.04 | *** join/#arm-netbook dfletcher (~fletch@108-196-222-251.lightspeed.sntcca.sbcglobal.net) |
| 00:30.40 | *** join/#arm-netbook dfletcher (~fletch@drupal.org/user/72475/view) |
| 00:32.13 | *** join/#arm-netbook dfletcher_ (~fletch@108-196-222-251.lightspeed.sntcca.sbcglobal.net) |
| 00:32.53 | *** join/#arm-netbook dfletcher_ (~fletch@drupal.org/user/72475/view) |
| 00:46.38 | *** join/#arm-netbook freakazoid0223 (~matt@pool-173-75-233-172.phlapa.fios.verizon.net) |
| 01:15.40 | *** join/#arm-netbook stefanro1 (~stefan@p57B95DEF.dip.t-dialin.net) |
| 01:40.05 | *** join/#arm-netbook dfletcher_ (~fletch@108-196-222-251.lightspeed.sntcca.sbcglobal.net) |
| 01:40.43 | *** join/#arm-netbook dfletcher_ (~fletch@drupal.org/user/72475/view) |
| 01:49.08 | *** join/#arm-netbook dfletcher (~fletch@108-196-222-251.lightspeed.sntcca.sbcglobal.net) |
| 01:49.31 | *** join/#arm-netbook dfletcher (~fletch@drupal.org/user/72475/view) |
| 02:28.05 | *** join/#arm-netbook cnxsoft (~cnxsoft@node-2wi.pool-118-172.dynamic.totbb.net) |
| 02:54.15 | *** join/#arm-netbook Dessimat0r (picard@108.59.4.114) |
| 02:58.16 | *** join/#arm-netbook ganbold_ (~Ganbold@202.21.108.36) |
| 04:14.51 | *** join/#arm-netbook MarcusSt (~nobody@p4FE987F1.dip0.t-ipconnect.de) |
| 04:28.02 | *** join/#arm-netbook aholler_ (~aholler@p57B20251.dip0.t-ipconnect.de) |
| 04:32.17 | *** join/#arm-netbook KoH__ (~kane@trir-5d8057bc.pool.mediaWays.net) |
| 04:33.13 | *** part/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
| 05:06.14 | *** join/#arm-netbook anunnaki (~anunnaki@c-174-54-115-236.hsd1.pa.comcast.net) |
| 05:54.49 | *** part/#arm-netbook discopig (~discopig@unaffiliated/discopig) |
| 06:03.36 | *** join/#arm-netbook Avernos (~avernos@222.128.145.34) |
| 06:03.36 | *** join/#arm-netbook Avernos (~avernos@unaffiliated/avernos) |
| 07:19.28 | *** join/#arm-netbook anunnaki (~anunnaki@c-174-54-115-236.hsd1.pa.comcast.net) |
| 07:20.11 | *** join/#arm-netbook anunnaki (~anunnaki@c-174-54-115-236.hsd1.pa.comcast.net) |
| 07:56.15 | *** join/#arm-netbook user135 (~user357@host109-157-97-139.range109-157.btcentralplus.com) |
| 08:02.20 | *** join/#arm-netbook Avernos (~avernos@unaffiliated/avernos) |
| 08:04.27 | *** join/#arm-netbook rm (rm@romanrm.hk) |
| 08:04.27 | *** join/#arm-netbook rm (rm@fsf/member/rm) |
| 08:25.27 | *** join/#arm-netbook xymox (lechuck@unaffiliated/contempt) |
| 08:50.41 | w00tc0d3 | wow |
| 08:50.47 | w00tc0d3 | <3 |
| 08:50.53 | w00tc0d3 | Ellie Goulding - Figure 8 |
| 09:04.55 | *** join/#arm-netbook rellla (~rellla@p5B0791CA.dip0.t-ipconnect.de) |
| 09:22.12 | *** join/#arm-netbook MarcusSt (~nobody@p4FE987F1.dip0.t-ipconnect.de) |
| 09:29.54 | *** join/#arm-netbook Alex1269 (550f6d7b@gateway/web/freenode/ip.85.15.109.123) |
| 09:31.38 | Alex1269 | Tried fresh stage/sunxi-3.4 on cubie... Still edid/fb problems - "Division by zero in kernel" in fb_videomode_pixclock_to_hdmi_pclk |
| 09:59.15 | *** join/#arm-netbook eebrah (~ibrah@212.49.88.103) |
| 10:25.38 | *** join/#arm-netbook zaxz (~zaxz@bl17-10-57.dsl.telepac.pt) |
| 11:14.34 | mnemoc | mv "$f" $"x" ...... /me cries after seeing half his music collection destroyed by a typo |
| 11:15.20 | mnemoc | Alex1269: report it on the mailing list please |
| 11:15.28 | *** join/#arm-netbook vgrade (~root@static.43.45.47.78.clients.your-server.de) |
| 11:17.48 | Alex1269 | Ok... i'll do this. mnemoc, I confirm subsys_initcall problem with gpio-sunxi - this is because sys_config stuff initialized later at fs_initcall level. Is there reasons against doing this in arch level ? |
| 11:18.16 | mnemoc | not really |
| 11:18.33 | mnemoc | please send the fixes :) |
| 11:19.02 | Alex1269 | Also I didn't found CONFIG_GPIO_SYSFS=y and CONFIG_EXPERIMENTAL=y options in configs needed to export gpios to sysfs |
| 11:21.05 | Alex1269 | Ooops. My fault, patches doesn't contain CONFIG_EXPERIMENTAL (our gpiolib version want this for sysfs) |
| 11:23.47 | mnemoc | ok. I'll re-run defconfig generation with CONFIG_EXPERIMENTAL=y CONFIG_GPIO_SYSFS=y |
| 11:24.45 | Alex1269 | I'll try to move sys_config init to arch level |
| 11:27.32 | Alex1269 | I have a patch adding a pull support to gpiolib/gpio-sunxi. What do you think - is possible to change gpiolib ? |
| 11:27.46 | br- | mnemoc: tell me you have a backup ;) |
| 11:27.55 | mnemoc | br-: no :< |
| 11:28.16 | br- | sends mnemoc a 2TB spinning rust drive worth $40 |
| 11:28.31 | mnemoc | br-: "in raid1 we trust" .... until the idiot deletes the stuff |
| 11:28.42 | br- | :( |
| 11:28.59 | br- | i drank too much sugar when younger, eventually learned to back things up, at least bi-monthly or so |
| 11:30.06 | br- | rm rf foo.*.txt! enter!enter!enter! this rm take too long!! slow computer *slurrrrp* *burp* wtf wtf! slow computer! ctrl+c!!!! <half a missing homedir> |
| 11:30.40 | mnemoc | Alex1269: as it will be controversial, let's wait a bit with the pull support thing |
| 11:31.03 | mnemoc | br-: :) |
| 11:32.05 | Alex1269 | Ok :) At least I have it for myself :) Now time to get normal ir driver.... |
| 11:36.35 | *** join/#arm-netbook tinti (~tinti@pdpc/supporter/student/tinti) |
| 11:47.40 | *** join/#arm-netbook tinti (~tinti@pdpc/supporter/student/tinti) |
| 11:53.14 | mnemoc | Alex1269: btw, there is an old ignored patch on the mailing list implementing a eirq driver which might deserve a 2nd look |
| 11:54.02 | Alex1269 | Any link ? :) |
| 11:54.22 | mnemoc | search for "[PATCH] Add external interrupt controller for sun4i/sun5i" |
| 11:54.40 | mnemoc | from dec. 7th |
| 11:59.55 | Alex1269 | Found. |
| 12:02.44 | Alex1269 | It is a very good idea to move eint part from gpio driver to arch init code. But this will lead to a bunch of changes in drivers... |
| 12:03.50 | Alex1269 | mnemoc, why this was ignored ? |
| 12:23.02 | Alex1269 | I moved sys_config init to arch level and this works... I |
| 12:23.12 | Alex1269 | i'll send a patch for this... |
| 12:25.28 | *** join/#arm-netbook aesok (~aesok@128-72-220-108.broadband.corbina.ru) |
| 12:26.18 | Alex1269 | After this we can change CONFIG_GPIO_SUNXI to =y |
| 12:28.45 | *** join/#arm-netbook Avernos_ (~avernos@222.128.152.51) |
| 12:29.13 | mnemoc | Alex1269: I was waiting for your gpiolib driver :) |
| 12:29.38 | Alex1269 | and add a simple driver adding a platform device for gpio input buttons :) This will allow to use hotplug subsystem for buttons and contacts |
| 12:31.33 | Alex1269 | I allready have water leak detector connected to cubie and LAMP server on it - I can switch off cold/hot water from work thru internet... :) |
| 12:35.28 | *** join/#arm-netbook focus_it (~focus_it@cpc7-dals17-2-0-cust182.hari.cable.virginmedia.com) |
| 12:42.26 | mnemoc | Alex1269: nice |
| 12:52.05 | theborger | so what is one of the better netbooks to buy? is the samsung chromebook good? or is there one cheaper/better? |
| 13:00.52 | *** join/#arm-netbook sky770 (~sky770@122.177.227.251) |
| 13:00.58 | mnemoc | theborger: imho the exynos5 chromebook is (still) unbeatable |
| 13:01.46 | *** join/#arm-netbook Avernos (~avernos@222.128.152.51) |
| 13:01.46 | *** join/#arm-netbook Avernos (~avernos@unaffiliated/avernos) |
| 13:04.06 | sky770 | morning all :D |
| 13:06.22 | *** join/#arm-netbook Avernos_ (~avernos@222.128.152.51) |
| 13:08.23 | mnemoc | theborger: but there is new chromebook coming, called pixel, you might want to wait and see if it's cortex-a15 aswell |
| 13:08.25 | Alex1269 | mnemoc, I sent two little patches: one for sys_config stuff and one for sunxi-3.4 gpio-sunxi (move to subsys init level) |
| 13:09.00 | Alex1269 | now switching to ir driver... :) |
| 13:09.47 | mnemoc | Alex1269: btw, for bin-compatibility, can you make a patch to keep gpio_request() when gpiolib is disabled? |
| 13:10.12 | mnemoc | there is a bunch of people still relying in gpl-violating .ko files in 3.0 |
| 13:10.37 | Alex1269 | it should return err ? |
| 13:12.01 | Alex1269 | brb |
| 13:14.07 | sky770 | theborger: rk3188 is out |
| 13:16.21 | *** join/#arm-netbook Alex1269 (550f7dbc@gateway/web/freenode/ip.85.15.125.188) |
| 13:18.51 | mnemoc | Alex1269: no, no just a #define to the symbol is called gpio_request instead of sunxi_gpio_request_array |
| 13:19.07 | theborger | i am looking for one i can hack. run fedora/slack/etc on |
| 13:19.30 | mnemoc | Alex1269: and so the gpl-violating drivers can find the symbol and.... work |
| 13:21.27 | Alex1269 | O... understood... It is a problem :( I forgot about binary drivers. |
| 13:21.56 | Alex1269 | I'll do this... |
| 13:24.28 | sky770 | the borger any other custom requirements? |
| 13:24.59 | sky770 | theborger: any other hardware requirements..? like the amount of RAM etc. etc? |
| 13:25.22 | focus_it | theborger: pengpods - there is a 12 point review in the comments section http://liliputing.com/2013/02/pengpods-linux-friendly-tablets-now-shipping-to-mixed-reviews.html |
| 13:26.53 | focus_it | http://www.pengpod.com - $110 for 7" Linaro (Ubuntu ARM derivative) Linux with the Linux booting from the flash. It behaves exactly like desktop computer. |
| 13:27.12 | Alex1269 | mnemoc, gpio_request was exported using EXPORT_SYMBOL_GPL(gpio_request); so binary drivers should be gpl to use it... |
| 13:27.36 | sky770 | focus_it: it has issues man |
| 13:28.33 | Alex1269 | They was declared as gpl but lacks source code... |
| 13:29.02 | sky770 | the pengpod (assuming the current shipping 7"/10" tabs) are using Allwinner A10 |
| 13:30.10 | theborger | sky770: no not really |
| 13:31.12 | theborger | i am looking at the samsung but i just did not want to spend 250 |
| 13:31.47 | theborger | the samsung is a dual core correct? or the exynos5 i should say |
| 13:32.06 | sky770 | http://pengpod.com/forum/viewtopic.php?f=6&t=466 (from the article linked above ^ :p |
| 13:32.51 | sky770 | brb |
| 13:35.44 | focus_it | sky778: I agree there are issues for whiny trolls :) |
| 13:35.45 | Gumboot | theborger: armbrix? |
| 13:36.08 | focus_it | I mean the device is new and there are bound to be immense technical problems as version 1 ships. |
| 13:36.42 | theborger | Gumboot: i have a Pi and a GuruPlug. thought about just getting a mototola atrix laptop dock, but really want a laptop based arm :) |
| 13:38.01 | sky770 | focus_it: it is not* about "as only version 1 has shipped" BUT it is about using an SoC which has scattered details/docs/source codes and most of which is incomplete. |
| 13:38.40 | sky770 | Gumboot: <3 armbrix :D |
| 13:38.50 | *** join/#arm-netbook rz2k (~rz2k@128-68-69-196.broadband.corbina.ru) |
| 13:39.05 | Gumboot | I'm tempted, but I don't fancy the shipping costs. |
| 13:39.13 | Gumboot | More particularly, I don't fancy their choice of courier. |
| 13:39.27 | sky770 | ^ yep .. :( |
| 13:39.38 | focus_it | sky770: tell me about it - I'm trying to make boards with it http://www.gplsquared.com/SoM2/SoM2.html |
| 13:40.02 | focus_it | Most of the other chip suppliers are even more crude - not disclosing their datasheets without an NDA |
| 13:40.13 | mnemoc | Alex1269: the gpl-violating drivers are marked as gpl as well |
| 13:40.14 | focus_it | No header files for internal hardware or datasheets |
| 13:41.16 | sky770 | focus_it: how about Freescale? a bit less rude? :| |
| 13:41.22 | focus_it | sky770: They shoot themselves in foot and their own throats instead of handing over datasheets. |
| 13:41.59 | sky770 | Freescale has comparatively better datasheets/info available around |
| 13:42.02 | focus_it | sky770: I'm working on it http://www.gplsquared.com/SoM3/SoM3.html - 6000 page datasheets |
| 13:42.16 | focus_it | but still nothing on internal workings of graphics acceleration |
| 13:42.32 | focus_it | kills a lot of projects and cheats their investors out of chip sales |
| 13:42.57 | sky770 | #ARM |
| 13:43.00 | sky770 | +1 |
| 13:43.38 | sky770 | also, I dunno..am somewhat less impressed than vivante 2k's perf. :( |
| 13:43.53 | focus_it | ARM cheats their investors too - they don't release header files for registers and bit fields. So ANY software ANYONE makes is incompatible with EVERYONE ELSE |
| 13:44.05 | sky770 | a mali-400 MP(4) rocks in comparison :D |
| 13:45.22 | sky770 | though am looking forward to etnaviv too :| |
| 13:45.23 | focus_it | Compare that with Microchip PICs - they sell 1 billion+ chips (slow ones), but all their registers and bit fields have names and even if the underlying hardware changes, one file that maps register names and bit fields repairs it all and makes old software work on new chips |
| 13:47.51 | *** join/#arm-netbook hg_5 (~chatzilla@unaffiliated/hg-5/x-8664886) |
| 13:51.31 | Alex1269 | mnemoc, I just can't figure out how to avoid ifdefs in code to implement this... To export there should be wrapper-function gpio_request with ifdefs |
| 13:59.17 | Alex1269 | Something like this: http://sprunge.us/MAjO?c (from line 461) |
| 14:10.58 | *** join/#arm-netbook sky770 (~sky770@122.177.21.117) |
| 14:10.58 | *** join/#arm-netbook focus_it (~focus_it@cpc7-dals17-2-0-cust182.hari.cable.virginmedia.com) |
| 14:11.20 | techn__ | current stage 3.0 doesnt compile :/ |
| 14:11.44 | mnemoc | techn__: eh?? |
| 14:11.58 | techn__ | /linux-sunxi/arch/arm/mach-sun4i/core.c:106:5: error: implicit declaration of function ‘sw_cfg_get_int’ [-Werror=implicit-function-declaration] |
| 14:12.24 | mnemoc | uhm |
| 14:13.40 | mnemoc | i might have missed a commit |
| 14:13.41 | mnemoc | 1m |
| 14:15.00 | techn__ | cant find header where that is declared :/ |
| 14:15.28 | mnemoc | it was removed |
| 14:15.51 | mnemoc | pre-iomapping works in 3.0 by miracle |
| 14:17.26 | mnemoc | it was removed from 3.4 ages ago |
| 14:17.43 | mnemoc | but somehow missed that commit when backporting plat-sunxi to 3.0 |
| 14:23.12 | Turl | hno: ping |
| 14:28.17 | Alex1269 | mnemoc, stage/3.4 has same problem yesterday but today problem gone |
| 14:28.46 | *** join/#arm-netbook ln2 (45f66366@gateway/web/cgi-irc/kiwiirc.com/ip.69.246.99.102) |
| 14:28.50 | mnemoc | o_O |
| 14:29.01 | ln2 | O_O |
| 14:30.29 | Alex1269 | It is related fb memory reservation |
| 14:30.59 | mnemoc | i can easy explain the problem in 3.0. but not in 3.4 |
| 14:32.51 | *** join/#arm-netbook eFfeM (~frans@c73189.upc-c.chello.nl) |
| 14:33.25 | Turl | make sure you're running 3.4 |
| 14:33.36 | mnemoc | techn__: test now |
| 14:34.45 | Alex1269 | mnemoc, sorry, 3.4 was ok... I had 3.0 compilation problem yesterday |
| 14:35.00 | techn__ | mnemoc: thanks. problem has gone |
| 14:36.00 | Alex1269 | mnemoc, look http://sprunge.us/MAjO?c (line 461) - is this ok ? |
| 14:37.01 | mnemoc | Alex1269: sprunge supports diff too :p |
| 14:37.21 | mnemoc | Alex1269: but yes, that sounds good |
| 14:37.28 | mnemoc | techn__: :) |
| 14:38.05 | Alex1269 | I known :) I didn't make it yet... |
| 14:38.24 | Alex1269 | So lets make a patch :) |
| 14:42.52 | ganbold_ | mnemoc: where was schematics of cubieboard? I'm looking for power pin for SD |
| 14:44.05 | mnemoc | ganbold_: dl.cubieboard.org |
| 14:45.39 | Alex1269 | sent |
| 14:46.51 | mnemoc | Alex1269: can you review hans patch to sunxi-leds? |
| 14:50.13 | *** join/#arm-netbook rellla (~rellla@p4FE56581.dip0.t-ipconnect.de) |
| 14:52.49 | L84Supper | oh man! No Kicad source files for the cubie?! :) |
| 14:54.21 | L84Supper | the pdf's actually look like they were created by somebody new to Cadence/Orcad Capture |
| 14:58.01 | xxiao | anyone attending http://www.linaro.org/connect/schedule |
| 15:06.39 | *** join/#arm-netbook rsalveti_ (~rsalveti@unaffiliated/rsalveti) |
| 15:07.22 | bfree | I've updated https://github.com/bfree/linux-sunxi-fll to be sane for the current state of my 3.4 deb packaging ... easiest way to review what I've done is probably there ;) ftr http://svn.berlios.de/viewvc/fullstory/linux-aptosid/ is the upstream for the packaging |
| 15:08.45 | Alex1269 | mnemoc, I read it - its ok for me... But i'm not sure if leds_default really needed because this can be done using gpio definition at leds_pin_n |
| 15:11.53 | *** join/#arm-netbook Quarx (~Quarx@178.74.77.223) |
| 15:12.33 | mnemoc | Alex1269: reply ;-) ... you are the driver author. it's part of the job |
| 15:15.57 | Turl | xxiao: there were allwinner people on one of those some year(s) ago |
| 15:21.14 | *** join/#arm-netbook vinifm (~Vinicius@177.206.172.160.dynamic.adsl.gvt.net.br) |
| 15:23.22 | xxiao | Turl: i saw that. last year it's free, this year it's $800 per attendee |
| 15:23.51 | xxiao | that may push chinese players away, who only thinks hardware worths money, if anything |
| 15:24.12 | xxiao | esp for money-tight small players |
| 15:24.30 | xxiao | i was just old only 5% are from mainland, 95% are from elsewhere |
| 15:24.47 | xxiao | and there are 300+ attendee already |
| 15:37.16 | *** join/#arm-netbook tinti (~tinti@pdpc/supporter/student/tinti) |
| 15:46.22 | *** join/#arm-netbook ZaEarl (~malmrose@c-67-172-235-190.hsd1.ut.comcast.net) |
| 16:00.51 | *** join/#arm-netbook ice_ (~irc@ppp-110-169-146-161.revip5.asianet.co.th) |
| 16:01.03 | ice_ | Good evening lads. |
| 16:01.18 | ln2 | Hello. =) |
| 16:01.25 | ice_ | What up ln2? |
| 16:01.55 | ln2 | Just hanging out waiting for exciting news. xD |
| 16:02.16 | ice_ | Hehehe |
| 16:04.19 | ice_ | Any idea how to compare reasonably (although that's like comparing oranges with apples) say an ATOM CPU from the 2009-2010 era vs. an ARM Cortex A8 CPU of 2012-2013 in terms of raw CPU calculation power? |
| 16:05.51 | specing | a8 is the 2010 era |
| 16:06.21 | specing | the atom will smash it to bits |
| 16:06.31 | ice_ | Alright. |
| 16:07.55 | buZz | well i am not sure, atom is not so good in FPU |
| 16:08.05 | jelly-home | ice_: the only reasonable approach is to run the actual workload on both |
| 16:09.45 | ice_ | I might have found some badass embedded smaller than mini itx propetary sized motherboards that come with an Intel ATOM 330, 1GB of DDR2 onboard, SATA & Gigabit ethernet integrated and can extend the memory to 4GB via standard SO-DIMM DDR2 sticks and all that at least than 49$/36 eur retail. |
| 16:11.41 | roxfan | atom has better performance but it's much hungrier |
| 16:12.03 | roxfan | and also needs more circuitry |
| 16:12.12 | ice_ | So that'd smash the f!*@# out of any ARM CPU stuff we can get our hands on at the moment I believe in terms of CPU calculation power, expandability to add RAM easily, low energy consumption and... x86 of course, hello Debian wheezy! |
| 16:13.05 | ice_ | I just have to negociate the price now, chinese are hard with business. :p |
| 16:13.15 | ln2 | There are already Intel SoC's. They will ship at the end of this year. 5 Watts power consumption. |
| 16:13.35 | ice_ | ln2, any URL? |
| 16:13.49 | ln2 | Clover Trail architecture. |
| 16:14.03 | ln2 | AMD also has x86 SoC's that are already shipping with 5 watts power. |
| 16:14.11 | roxfan | weren't there some phones with intel chips already? |
| 16:14.28 | ln2 | Yes. None in the US. |
| 16:14.37 | mnemoc | an 30m of battery life? |
| 16:14.42 | mnemoc | and* |
| 16:14.46 | ln2 | Same as ARM. |
| 16:14.48 | roxfan | hehe |
| 16:14.59 | ice_ | Oh and apologies in advance for discussing x86 stuff on an... ARM channel. :-) |
| 16:15.13 | ln2 | That's ok. I think really we are interested in low power hardware. |
| 16:15.21 | ln2 | BRB |
| 16:18.56 | ice_ | CPU at 5%: 17.7W http://imgur.com/x9YIYaC |
| 16:19.36 | ice_ | CPU at 30%: 23.7W http://imgur.com/P7FFT2e |
| 16:20.25 | ice_ | System off, just waiting to be waken on LAN: 2.1W http://imgur.com/79atwBQ |
| 16:26.26 | *** join/#arm-netbook MarcusSt (~nobody@p4FE987F1.dip0.t-ipconnect.de) |
| 16:26.33 | jelly-home | 2W is quite a lot for something calling itself "off" |
| 16:26.47 | ice_ | That's wake on LAN. |
| 16:26.59 | L84Supper | ice_: finding quality board stuffers is the difficult part, pricing is actually pretty easy, they expect you to shop around same as they do |
| 16:28.37 | ice_ | Indeed. |
| 16:29.10 | L84Supper | finding quality anything there is the actual challenge |
| 16:29.39 | ice_ | Welcome to china, welcome to the future! |
| 16:30.45 | L84Supper | treat it like you would a child that doesn't want to do something and will try every trick to not finish a required task |
| 16:31.32 | L84Supper | they figure if you don't notice, then it's fine |
| 16:31.45 | L84Supper | that's pretty much the attitude |
| 16:31.55 | ice_ | You speaking of experience with them? |
| 16:32.11 | L84Supper | yes |
| 16:32.17 | L84Supper | children and china |
| 16:32.20 | ice_ | We're borderline racism here, let's keep it civil. |
| 16:32.56 | L84Supper | not at all |
| 16:33.19 | L84Supper | it's an over generalization |
| 16:33.26 | ice_ | Or let's just NOT turn it into a "bashing country" contest. |
| 16:33.51 | ice_ | brb anyways |
| 16:33.51 | L84Supper | not at all, i actually have a business there |
| 16:36.06 | *** join/#arm-netbook ice_ (~irc@ppp-124-121-199-70.revip2.asianet.co.th) |
| 16:36.27 | ice_ | L84Supper, so what kind of business do you have? |
| 16:36.57 | L84Supper | R&D and manufacturing |
| 16:37.52 | L84Supper | i don't set policy, I just observe it |
| 16:39.41 | ice_ | L84Supper, mind if I poke you in /msg? |
| 16:40.18 | *** join/#arm-netbook rz2k (~rz2k@93-80-85-167.broadband.corbina.ru) |
| 17:23.53 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 17:27.53 | *** join/#arm-netbook penguin42 (~dg@tu006.demon.co.uk) |
| 17:34.07 | *** join/#arm-netbook Quarx (~Quarx@178.74.77.223) |
| 17:45.16 | *** join/#arm-netbook cocos (4dfd3572@gateway/web/freenode/ip.77.253.53.114) |
| 17:55.10 | *** join/#arm-netbook MMlosh_ (~MMlosh@2001:470:6f:23:f818:e67:a96e:a2f7) |
| 18:04.25 | gzamboni | what does this new gpio driver does in aditional with the ugly gpio old one ?? IRQ external int support ? |
| 18:05.32 | gzamboni | is there another way of using gpios in c programming besides of using the sys/ ... filesystem ? |
| 18:11.29 | *** join/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
| 18:11.29 | *** part/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
| 18:13.53 | RaYmAn | the gpio stuff is usually used by other drivers |
| 18:23.01 | *** part/#arm-netbook Skrzyp (~skrzyp@unaffiliated/skrzyp) |
| 18:26.05 | specing | gzamboni: mmaping() /dev/ram and accessing the GPIO module directly |
| 18:30.07 | mnemoc | it might be a good idea to make a lib out of sunxi-tools' pio.c |
| 18:31.07 | mnemoc | with the obvius problem of requiring uid 0 |
| 18:33.48 | specing | CAP_GPIO ? :D |
| 18:34.26 | specing | it probably doesen't exist |
| 18:34.42 | specing | But there sure is some capability that flows with the purpose |
| 18:35.03 | mnemoc | specing: it's the access to /dev/mem that is obviusly restricted |
| 18:35.44 | specing | Oh so we are not talking about the /sys stuff, are we? |
| 18:37.02 | mnemoc | he wanted to avoid accessing each pin as fd |
| 18:37.41 | gzamboni | i did with an olimex board using imx233, i did accessed direclty including a gpio-mmap.h |
| 18:37.59 | gzamboni | for the test i made it is much faster than accessing the files from the sys dir |
| 18:38.50 | mnemoc | sunxi-tools's pio.c knows to work with the pio register from userspace |
| 18:39.04 | mnemoc | it can be refactored into a library |
| 18:39.18 | mnemoc | but anyhow, /dev/mem access (to mmap) requires root |
| 18:39.40 | techn__ | mnemoc: please apply that divide-0 patch.. its showstopper currently :) |
| 18:39.57 | mnemoc | drachensun's inline diff? |
| 18:39.59 | gzamboni | i havent saw yet this pio.c from the sunxi tools, let me check |
| 18:40.21 | techn__ | hans's patch is beter imho |
| 18:41.18 | mnemoc | ah, sorry. didn't see it coming |
| 18:42.19 | gzamboni | i saw the presentation of libv at fosdem. grate work you are all doing |
| 18:42.54 | *** join/#arm-netbook anunnaki (~anunnaki@c-174-54-115-236.hsd1.pa.comcast.net) |
| 18:44.44 | gzamboni | And connor aparently is a genius. When i had his age i was learning html code :P |
| 18:46.12 | techn__ | gzamboni: I programmed my first lines 20 years ago :p |
| 18:46.24 | *** join/#arm-netbook lerc (~quassel@121-74-230-95.telstraclear.net) |
| 18:46.39 | techn__ | but that was about 10 lines of turbo bascal.. nothing like connor :D |
| 18:48.09 | mnemoc | wonders if gpiolib provides an standard mmap/ioctrl interface to the whole banks |
| 18:48.38 | mnemoc | not the same as raw access to the registers, but should be a good middle point |
| 18:49.10 | gzamboni | i am learning a lot here and in the ml and looking at the patches, for the moment im in spector mode |
| 18:50.27 | gzamboni | i did program already in c and asm, but it wasnt like in the kernel with buffers and all those file relationships |
| 18:50.49 | mnemoc | techn__: divide by zero is stage-only or on the main branches too? |
| 18:51.11 | techn__ | I reproduced that problem only with current stage |
| 18:51.27 | techn__ | so stage only :/ |
| 18:52.05 | mnemoc | pushed |
| 18:52.06 | techn__ | but it wouldn't hurt non-stage if it applies |
| 18:52.10 | techn__ | ok :) |
| 18:58.48 | *** join/#arm-netbook fdgdfgd (4dfd3572@gateway/web/freenode/ip.77.253.53.114) |
| 19:07.51 | *** join/#arm-netbook OmegaPhil (~kvirc@fsf/member/OmegaPhil) |
| 19:21.35 | *** join/#arm-netbook simosx (~simosx@178.128.109.69.dsl.dyn.forthnet.gr) |
| 19:21.35 | *** join/#arm-netbook simosx (~simosx@ubuntu/member/simosx) |
| 20:02.42 | *** join/#arm-netbook user135 (~user357@host86-157-217-65.range86-157.btcentralplus.com) |
| 20:03.26 | user135 | Hello, is there a free software driver for sunxi's 8192cu? |
| 20:05.27 | user135 | If so, does anyone know where I can get the latest sources? |
| 20:05.48 | specing | http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git&a=search&h=HEAD&st=commit&s=8192 |
| 20:07.25 | Turl | user135: the kernel tree already has both drivers available |
| 20:07.46 | Turl | rtlwifi and realtek's own ugly rtl8192cu |
| 20:08.45 | user135 | okay, thanks, that's good news :) |
| 20:25.45 | *** join/#arm-netbook MMlosh (~MMlosh@2001:470:6f:23:55c8:5e6d:b745:d792) |
| 20:35.30 | vinifm | how a platform driver spi knows how many bytes a chip driver want read and write at same time? |
| 20:40.07 | libv | my synapses seem to remember someone complaining about Xlib error messages |
| 20:40.11 | libv | upon quit |
| 20:40.15 | libv | ssvb, was that you? |
| 20:40.31 | libv | http://stackoverflow.com/questions/8176493/how-do-you-exit-x11-program-without-error |
| 20:41.11 | libv | seems like Xlib has been broken over the last 2 decades, or at least, it has been badly wrapped by the wm |
| 20:41.59 | ssvb | libv: I think it was hramrach |
| 20:42.17 | libv | ah, ok |
| 20:42.48 | libv | in any case, that howto i pointed to, as well as any hello world with xlib, has this error |
| 20:44.00 | libv | apart from that, it really was just a bit of busywork to use xlib and egl |
| 20:46.35 | ssvb | libv: IIRC es2_info failed on exit, valgrind reported some sort of "use after free" problem |
| 20:47.24 | *** join/#arm-netbook L84Supper (~Larch@unaffiliated/l84supper) |
| 20:47.36 | libv | heh, a fresh run of es2_info just hangs with me now :) |
| 20:47.52 | libv | X is broken |
| 20:48.14 | libv | sadly, the same mindset that broke X is at work creating the follow-up, and reinventing everything along the way |
| 20:48.18 | ssvb | or in this case the mali blob :) |
| 20:48.31 | libv | i think it used to return nicely before |
| 20:48.36 | libv | or at least returned |
| 20:48.43 | ssvb | but we can't really debug it properly :-/ |
| 20:49.24 | libv | heh, it does get a DestroyNotify |
| 20:49.38 | libv | (says xtrace) |
| 20:50.28 | libv | kills the xserver and tries again |
| 20:51.23 | libv | ssvb: i rather believe atm that this is not a mali-libs issue |
| 20:54.26 | ssvb | libv: after looking at xf86-video-mali code, I'm not so sure. I guess it could be so that the X11/DRI2 integration was done by some junior developers, and the X11 code might be just as ugly on the blob side... |
| 20:55.13 | libv | ssvb: xtrace tells me that es2_info gets a DestroyNotify |
| 20:55.20 | libv | ssvb: yet es2_info does not quit. |
| 20:58.52 | ssvb | libv: es2_info is linking libMali.so, and it has some X11 related code for EGL residing in this blob (at least for requesting DRI2 buffers), this code could be screwing up something |
| 20:59.00 | ssvb | libv: but that's just a guess |
| 20:59.22 | *** join/#arm-netbook abesis (~abesis@217.131.210.89) |
| 20:59.37 | libv | i have been near the X.org community for long enough to know that the binary is not always the issue. |
| 21:04.14 | ssvb | libv: if you can find the root cause for this problem, that would be really great :-) |
| 21:07.00 | *** join/#arm-netbook alcides (~alcides@177.17.153.202) |
| 21:07.00 | *** join/#arm-netbook alcides (~alcides@unaffiliated/alcides) |
| 21:08.17 | *** join/#arm-netbook MMlosh (~MMlosh@2001:470:6f:23:55c8:5e6d:b745:d792) |
| 21:12.04 | ssvb | libv: as a somewhat unrelated thing, I have taken care to eliminate OpenGL (libGL.so) on my old x86 laptop a few days ago, this should make it a bit easier to do GLESv2 compatibility testing |
| 21:13.33 | *** join/#arm-netbook aesok (~aesok@128-72-220-108.broadband.corbina.ru) |
| 21:55.17 | hramrach | libv: this is what X11 support in the mali-libs test program looks like: https://github.com/hramrach/mali-libs/commit/ff1365c2c08e7f8203361a79c5a309c37fe1e6ef |
| 21:56.23 | hramrach | but can't get the mesa demos eglut from which I got the X11 code to work with Mali fb libraries |
| 21:59.12 | hramrach | the es2_info program is particularly broken. Unlike other X programs it manages to corrupt its memory |
| 21:59.24 | hramrach | you get glibc error if you run it a few times |
| 21:59.46 | hramrach | ssvb: |
| 21:59.59 | *** join/#arm-netbook marcus__ (~nobody@p4FE991A1.dip0.t-ipconnect.de) |
| 22:00.47 | techn__ | something is really broken if process leaves garbage behind |
| 22:01.44 | techn__ | memory leak in kernel? |
| 22:02.03 | ssvb | techn__: valgrind tells me that it is the use of "memory buffer after free" problem |
| 22:02.29 | techn__ | yeah.. but that should be inside that process? |
| 22:02.30 | ssvb | techn__: no need to leave garbage behind if you can do it wrong on every run :) |
| 22:02.46 | techn__ | and process dies after that |
| 22:03.07 | techn__ | but if it effects to next run.. problem should be in kernel |
| 22:03.14 | ssvb | not really |
| 22:03.30 | ssvb | you just get unpredictable results on every run |
| 22:04.13 | techn__ | also X or other server process could be reason |
| 22:04.41 | hramrach | well, no. the program manges its memory |
| 22:04.43 | ssvb | yes, maybe |
| 22:05.31 | ssvb | I mean anything in the system might have indirect influence on the bugs with unstable reproducibility |
| 22:05.33 | techn__ | hramrach: yes but kernel should cleanup open handles when that process dies |
| 22:05.55 | hramrach | does it not? |
| 22:11.41 | ssvb | the es2_info program is a bit special because it does not try to render anything |
| 22:12.46 | ssvb | could it be that the mali code gets confused by this (by relying on some sort of lazy initialization of some structures on certain API calls which are missing in es2_info)? |
| 22:13.15 | ssvb | hramrach: is there anything else that is failing for you (other than gnome-shell)? |
| 22:15.24 | *** join/#arm-netbook FergusL (~PetitLol@2a01:e0b:1000:33:5054:ff:fe00:1d0) |
| 22:16.25 | ssvb | hramrach: also what exactly is wrong with eglut demos? |
| 22:23.47 | *** join/#arm-netbook Makawity (b0c72a92@gateway/web/freenode/ip.176.199.42.146) |
| 22:24.34 | Makawity | hi there |
| 22:25.08 | hramrach | ssvb: they run fine in X11 but use some Mesa specific extensions when not under X11 |
| 22:26.30 | hramrach | and gnome-shell is working as poorly as ever, no problem with that |
| 22:26.42 | hramrach | thanks for bringing back the windows :) |
| 22:28.14 | *** part/#arm-netbook Makawity (b0c72a92@gateway/web/freenode/ip.176.199.42.146) |
| 22:28.17 | ssvb | hramrach: I still need to bring back the ARGB cursor (in the case when layers are used) :) |
| 22:29.24 | ssvb | hramrach: have you tried any other compositing managers? kwin_gles seems to work reasonably good |
| 22:30.42 | *** join/#arm-netbook revident (~scott@fw.iplink.net) |
| 22:34.36 | *** join/#arm-netbook discopig (~discopig@unaffiliated/discopig) |
| 22:36.24 | hramrach | ssvb: not yet |
| 22:36.40 | hramrach | running out of space on the card |
| 22:41.18 | libv | i think i would have to conclude that our egl is indeed broken |
| 22:42.20 | libv | mali_egl_cleanup_internal is a destructor called when libc is tearing down |
| 22:42.56 | libv | it is even being run after the xdisplay has been closed |
| 22:43.20 | ln2 | Does anyone know the maximum resolution of the A10's 24 pin TTL output? |
| 22:43.49 | libv | and to clean up some of its own surfaces, it tries to initialize the DRI2 extension |
| 22:44.21 | libv | on a closed display... |
| 22:51.24 | libv | maybe by hexediting a nop into __LINUXeglDestructor, we can circumvent this |
| 22:52.15 | ssvb | libv: if it only affects es2_info, then it might be not so important? |
| 22:53.22 | libv | i believe that it affects every program that tries to clean up X on exit |
| 22:54.13 | ssvb | libv: don't "normal" applications trigger the initialization of DRI2 way before the teardown? |
| 22:54.52 | libv | ssvb: the issue is that we try to re-initialize after the display has been torn down already |
| 22:55.36 | ssvb | in every case or only reproducible with es2_info? |
| 22:58.42 | libv | i am getting the same in my hacked test program |
| 22:58.47 | libv | and hramrach is getting this issue too |
| 23:00.58 | ssvb | ok, confirmed, I can also reproduce this with a simple program |
| 23:01.55 | libv | bx lr fixes it apparently |
| 23:02.45 | ssvb | we may want to check if the offending code might be in fact in libdri2 |
| 23:02.54 | libv | mnemoc: i have just succesfully hacked r3p0-hf-x11 to not deadlock or crash upon exit, when the xdisplay has been closed already |
| 23:03.32 | libv | ssvb: imho there should be any attempt to clean up anything |
| 23:03.40 | libv | should not even |
| 23:04.09 | libv | the kernel should clean up on its own, X and the DRI2 extension should clean up when the client vanishes |
| 23:04.54 | libv | the fact that we try to clean up things which have vanished already, as our client application did so for us, is exactly what runs us into trouble |
| 23:05.08 | libv | so i think it is perfectly legal to not do anything specific on exit() |
| 23:05.18 | libv | kernel and X should do the right thing |
| 23:05.57 | ssvb | does anything look familiar here https://github.com/robclark/libdri2/blob/master/src/dri2.c ? |
| 23:06.30 | ssvb | it tries to do DRI2FindDisplay and XextCheckExtension in every function |
| 23:06.58 | ssvb | without much error checking |
| 23:09.20 | ssvb | libv: libMali.so might contain some wacky code, but I don't believe that it was not tested at least in some environment |
| 23:09.38 | ssvb | and this other environment could have been a bit more forgiving |
| 23:12.43 | libv | ssvb: i think that the X egl was not thoroughly tested |
| 23:13.02 | libv | ssvb: how often have you seen mali binaries for X? |
| 23:13.39 | libv | i am pretty certain that the surfaceflinger egl is a lot more robust |
| 23:14.18 | *** join/#arm-netbook Turl (~Turl@cyanogenmod/maintainer/Turl) |
| 23:14.18 | ssvb | sure |
| 23:14.21 | libv | i also currently believe that attempting to clean up dri2 drawables after XCloseDisplay is wrong |
| 23:14.31 | libv | but it indeed might pay to shore up libdri2 |
| 23:14.44 | libv | sadly though: |
| 23:14.46 | libv | #11 0x4016f88e in DRI2DestroyDrawable () from /usr/lib/libEGL.so |
| 23:15.17 | ssvb | heh |
| 23:15.23 | libv | so libdri2 seems compiled into libMali.so |
| 23:15.44 | ssvb | what's even worse, it is partially compiled |
| 23:16.51 | ssvb | it wants DRI2SwapBuffers to be provided by something else |
| 23:17.26 | libv | :) |
| 23:17.35 | libv | our libMali.so is a mess |
| 23:17.40 | libv | but at least we have one |
| 23:17.48 | ssvb | yeah, we have some sort of a badly patched frankensteiner |
| 23:17.59 | libv | so maybe this hexedit is the way to go |
| 23:18.15 | techn__ | hopefully we'll get OSS version of that ;) |
| 23:18.35 | libv | techn__: yeah, sure, it'll be done tomorrow |
| 23:19.01 | libv | ssvb: http://hastebin.com/jekuyawexe.diff |
| 23:21.22 | rz2k | dri2 import is fixed in r3p2 |
| 23:21.27 | rz2k | available from hardkernel |
| 23:21.46 | rz2k | only kernelside needs to be ported to new version of driver platform definition |
| 23:21.50 | libv | ssvb: what do you think, after that things work as expected |
| 23:21.57 | rz2k | they now dont use the config.h |
| 23:23.42 | libv | here is the backtrace btw http://hastebin.com/fijugupema.vala |
| 23:33.52 | OmegaPhil | Thankyou for your work libv (random GNU/Linux x86_64 user passing by) |
| 23:34.10 | libv | :) |
| 23:36.09 | libv | i am going to push this change directly, mnemoc can kill me for it in the morning |
| 23:37.55 | techn__ | libv linking order could solve that issue also :/ |
| 23:38.17 | techn__ | or hide problem :D |
| 23:38.21 | libv | nope |
| 23:38.33 | libv | part of libdri2 is compiled in |
| 23:39.41 | libv | 5d4ba:f001 f9e3 blahee 5e884 <DRI2DestroyDrawable> |
| 23:39.48 | *** join/#arm-netbook abesis2 (~abesis@217.131.210.89) |
| 23:40.00 | techn__ | yeah |
| 23:40.09 | libv | bl 5e884 <DRI2DestroyDrawable> |
| 23:40.19 | libv | so a direct jump, no chance of intercepting that |
| 23:46.26 | hramrach | ugh, I thought gnome is slow to start |
| 23:46.29 | hramrach | but kde .. |
| 23:47.01 | penguin42 | hramrach: There is a light config I think for tablets you can configure; you can also configure it's desktop effects/GL stuff off |
| 23:47.21 | penguin42 | it's lovely and fast on my desktop with an SSD |
| 23:47.42 | hramrach | I have a SD card ;-) |
| 23:47.53 | penguin42 | yeh, you just want to get the other S and you'll be sorted |
| 23:49.58 | hramrach | it runs at reasonable speed but takes very long to start |
| 23:50.22 | penguin42 | hramrach: Do anything you possibly can to reduce the number of writes you do |
| 23:50.23 | ssvb | hramrach: actually right now I'm just starting xfce4 and then running "kwin_gles --replace" for testing |
| 23:50.23 | hramrach | gnome used to have that problem but starts faster in 3 |
| 23:51.09 | hramrach | comparing gnoe and kde kde has way faster overall UI - probably fewer large scale effects |
| 23:51.20 | hramrach | but its window resize sucks |
| 23:52.12 | hramrach | hmm, I have xrender compositing, no GLES |
| 23:52.26 | hramrach | where do you get kwin_gles? |
| 23:53.19 | ssvb | well, maybe this depends on the distro |
| 23:54.34 | ssvb | with xrender compositing you just get NEON code running on the CPU, it is fast for simple effects, such as translucency |
| 23:55.01 | ssvb | hramrach: is there just "kwin" binary, but not "kwin_gles"? |
| 23:55.25 | FergusL | (are you talking about a specific device/board ?) |
| 23:56.19 | jelly-home | ssvb: which distro builds "kwin_gles"? |
| 23:56.46 | hramrach | ssvb: yes, only kwin |
| 23:57.34 | hramrach | jelly-home: Debian has gnome-hell built against libgles, you are not missing out ;-) |
| 23:58.20 | libv | hrm, a merge for a single commit... |
| 23:58.29 | jelly-home | hramrach: I don't use gnome, only xfce and kde |