• [00:19:34] * JDuke128 (~kadir@81.214.22.138) has joined #beagle
  • [00:28:55] <JDuke128> hi , i m using igepv2 card tried to use openembedded angstrom , all works fine except wifi , angstrom cant dedect wifi ? how can i make it dedect ?
  • [00:39:05] <maluta> _av500_: just to point te previous conversation. I put on a black sd cart the image and booted. The X-Loader started loading U-Boot from mmc. At U-Boot the system stops on line i2c: ready
  • [00:45:10] <aszpain> well I give up... the state of TEXAS is in debt with me for the sum of 149$.... cannont make the EHCI USB to work properly :(
  • [00:48:47] <aszpain> has C4 any considerable bug?
  • [00:52:53] * maqr (~maqr@httpcraft/hax) Quit (Read error: Connection reset by peer)
  • [00:53:10] * maqr (~maqr@httpcraft/hax) has joined #beagle
  • [00:53:10] * maqr (~maqr@httpcraft/hax) Quit (Read error: Connection reset by peer)
  • [01:03:39] * maqr (~maqr@httpcraft/hax) has joined #beagle
  • [01:09:46] <JDuke128> hi , i m using igepv2 card tried to use openembedded angstrom , all works fine except wifi , angstrom cant dedect wifi ? how can i make it dedect ?
  • [01:12:22] * Dead1nside (~Dead1nsid@78.86.212.180) Quit (Ping timeout: 240 seconds)
  • [01:21:21] * me345 (~me345@adsl-75-15-239-47.dsl.bkfd14.sbcglobal.net) has joined #beagle
  • [01:25:44] * Dead1nside (~Dead1nsid@78.86.212.180) has joined #beagle
  • [01:32:21] * katie (~katierh@nat/ti/x-jkxkknuubcdsuyni) Quit ()
  • [01:46:03] * emeb-eee (~ericb@75-174-203-213.phnx.qwest.net) Quit (Ping timeout: 252 seconds)
  • [01:52:11] * cecil_lincher (~clincher@pool-173-63-114-102.nwrknj.fios.verizon.net) has joined #beagle
  • [01:55:33] * merlin_ (adceee91@gateway/web/freenode/ip.173.206.238.145) has joined #beagle
  • [01:55:55] <merlin_> any music servers built with the beagle board?
  • [01:58:09] * merlin_ (adceee91@gateway/web/freenode/ip.173.206.238.145) Quit (Client Quit)
  • [02:01:42] * Redb3ard (~SF0010MAC@75.110.202.83) has joined #beagle
  • [02:07:50] * ckrinke (~IceChat7@76-218-61-186.lightspeed.irvnca.sbcglobal.net) Quit (Quit: On the other hand, you have different fingers.)
  • [02:42:40] * raster (~raster@enlightenment/developer/raster) has joined #beagle
  • [02:48:01] * DHowett (~dustin@nix.howett.net) Quit (Quit: leaving)
  • [02:54:50] * khasim (~a0393720@192.163.20.231) has joined #beagle
  • [02:59:12] * aszpain (~fuldrul@85.66.18.95.dynamic.jazztel.es) Quit ()
  • [03:04:02] * cody (~cody@dslb-084-056-116-217.pools.arcor-ip.net) Quit (Ping timeout: 240 seconds)
  • [03:04:47] * Aerhead (61703434@gateway/web/freenode/ip.97.112.52.52) has joined #beagle
  • [03:05:53] * Aerhead (61703434@gateway/web/freenode/ip.97.112.52.52) Quit (Client Quit)
  • [03:06:15] * cody (~cody@dslb-084-056-074-178.pools.arcor-ip.net) has joined #beagle
  • [03:23:35] * RobotGrrl (~RobotGrrl@bas2-montreal50-2925252324.dsl.bell.ca) has joined #beagle
  • [03:26:25] * Redb3ard (~SF0010MAC@75.110.202.83) Quit (Quit: Redb3ard)
  • [03:26:28] * ghoti_ (~paul@38.117.126.254) Quit (Read error: No route to host)
  • [03:26:37] * ghoti (~paul@38.117.126.254) has joined #beagle
  • [03:31:23] * ghoti (~paul@38.117.126.254) Quit (Ping timeout: 245 seconds)
  • [03:32:28] * ghoti (~paul@38.117.126.254) has joined #beagle
  • [03:41:45] * radhermit (~radhermit@radhermit-1-pt.tunnel.tserv3.fmt2.ipv6.he.net) Quit (Read error: Operation timed out)
  • [03:42:52] * me345 (~me345@adsl-75-15-239-47.dsl.bkfd14.sbcglobal.net) Quit (Read error: Connection reset by peer)
  • [03:43:19] * me345 (~me345@adsl-75-15-239-47.dsl.bkfd14.sbcglobal.net) has joined #beagle
  • [03:43:53] * radhermit (~radhermit@radhermit-1-pt.tunnel.tserv3.fmt2.ipv6.he.net) has joined #beagle
  • [03:45:33] * aholler_ (~aholler@p57B22306.dip0.t-ipconnect.de) has joined #beagle
  • [03:48:54] * me345 (~me345@adsl-75-15-239-47.dsl.bkfd14.sbcglobal.net) Quit (Remote host closed the connection)
  • [03:48:56] * aholler (~aholler@p57B225E5.dip0.t-ipconnect.de) Quit (Ping timeout: 260 seconds)
  • [03:56:48] <CruNcher> did someone benchmarked Samsungs S5PC100 Cortex A8 vs a TI comparable chip say the 3440 ?
  • [03:57:13] <CruNcher> or maybe a Device itself ;) vs a TI based Device :D
  • [03:57:59] * thaytan (~jan@ppp59-167-167-201.static.internode.on.net) Quit (Ping timeout: 265 seconds)
  • [03:58:22] <CruNcher> somethning like Odroid vs OpenPandora and Archos 5IT ;)
  • [03:59:37] <raster> CruNcher: yes
  • [03:59:44] <CruNcher> results :) ?
  • [04:00:09] <raster> c100 thrashes a 3430 (dont have a 3440)
  • [04:00:59] <CruNcher> c100 has a DSP part for Video Playback ?
  • [04:01:35] <raster> silicon for video playback
  • [04:01:42] <raster> not dsp
  • [04:01:46] <CruNcher> ohhh
  • [04:01:48] <raster> well nothing programmable as i know
  • [04:01:58] <CruNcher> what is it capable of ?
  • [04:02:06] <raster> http://www.rasterman.com/files/n900vsxxx.html
  • [04:02:30] <raster> n900 (omap3430 @ 600mhz vs s5pc110 @ 800mhz (xxx))
  • [04:02:40] <raster> thats software doing rendering of gfx
  • [04:03:19] <CruNcher> not really fair
  • [04:03:29] <raster> well both doing software rendering
  • [04:03:30] <CruNcher> 200 mhz less
  • [04:03:37] <raster> both same identical code
  • [04:03:38] <CruNcher> the 3440 would be fairer to compare
  • [04:03:43] <raster> sure
  • [04:03:57] * emeb|mac (~ericb@ip72-223-81-194.ph.ph.cox.net) has joined #beagle
  • [04:04:06] <raster> but an extra 33% in clockrate - the performance comes out 147% better
  • [04:04:32] <raster> there is much more to an soc than just its cpu clockrate
  • [04:04:37] <raster> u have a memory bus to consider too
  • [04:04:49] <raster> and whatever memory chips u have paired with it
  • [04:04:58] <raster> as well
  • [04:05:08] <raster> the c110 has a much better memory subsystem
  • [04:05:12] <raster> and it shows
  • [04:05:31] <CruNcher> i see
  • [04:05:31] <raster> if all u think of is cpu clockrate
  • [04:05:42] <raster> then drop the c110's perf numbers by 25%
  • [04:05:53] <raster> then u have youre "apples vs apples" comparison
  • [04:05:58] <raster> but there's much more to it than that :)
  • [04:06:05] <raster> thats why i tell u the clockrates
  • [04:06:07] <raster> i'm being fair :)
  • [04:06:14] * RobotGrrl (~RobotGrrl@bas2-montreal50-2925252324.dsl.bell.ca) Quit (Quit: RobotGrrl)
  • [04:06:18] <CruNcher> hehe
  • [04:06:26] <raster> both are otherwise equivalent
  • [04:06:29] <raster> both render in x11
  • [04:06:34] <raster> both render the same resolution
  • [04:06:37] <raster> same bith depth
  • [04:06:44] <raster> both have composiing turned off
  • [04:06:45] <raster> etc.
  • [04:06:59] <raster> i can tell u the gpu in the c110 absolutley walks all over the gppu oin the omap3
  • [04:07:00] <CruNcher> how about the energy side ;) ?
  • [04:07:04] <raster> sgx 530 cs 540
  • [04:07:13] <raster> the 540 comes in at something like 3-4x faster
  • [04:08:59] <raster> i cant find my numbers for that - but trust me that i've done them :)
  • [04:09:03] <raster> enegry - don 't know
  • [04:09:13] <raster> but my guess is they come in at the same power usage give or take
  • [04:09:28] <raster> ie they are in similar devices of similar size and similar battery capacities
  • [04:09:33] <raster> etc.
  • [04:09:40] <CruNcher> yeah
  • [04:09:58] <raster> so sure - u might see up to something 50% difference betwreen them
  • [04:10:00] <raster> UP to
  • [04:10:06] <raster> more likely the 10-20% range
  • [04:10:13] <raster> but thats within "its the same balllpark" range
  • [04:10:30] <raster> if u are making a product u djust accordingly with battery scapacity
  • [04:10:33] <raster> (and thus size)
  • [04:10:50] <raster> as such the c110 is a much newer soc than the 3430 tho
  • [04:10:55] <raster> so it has a big advantage
  • [04:11:10] <raster> but if u are in charge of deciding what soc to use
  • [04:11:20] <CruNcher> Samsungs first official Video Playback Demo looked also nice though that is also no problem on the TI DSP
  • [04:11:23] <CruNcher> http://www.youtube.com/watch?v=tSrsGPgIsEQ
  • [04:11:26] <raster> and u have been given an omap3430 or a s5pc110 to choose from - i'd go the samsung part
  • [04:12:08] <raster> last i heard the c110 can do full 1080p 30fps playback
  • [04:12:25] <CruNcher> wow
  • [04:12:27] <raster> but the omap3430 cant only squeeze out 720p 30fps
  • [04:12:41] <CruNcher> i dunno if any 3rd party reached that on the TI DSP yet :P
  • [04:12:44] <raster> (h264 i think)
  • [04:12:49] <CruNcher> i doubt though
  • [04:12:51] <raster> i dont think so
  • [04:12:57] <raster> but samsung are proud of mannaing full hd
  • [04:13:01] <raster> not rellevant for phones/handsets
  • [04:13:07] <raster> but for a set to pobx or tv it is
  • [04:13:13] * chainsawbike_ (~chainsawb@202-0-50-230.cable.telstraclear.net) has joined #beagle
  • [04:13:18] <CruNcher> yeah odroid :)
  • [04:13:29] <CruNcher> with the HDMI out perfect for that :)
  • [04:13:50] <raster> tho note
  • [04:13:52] <raster> i talk of the c110
  • [04:13:54] <raster> not the c100
  • [04:13:58] <CruNcher> the c110 is the successor of the c100 ?
  • [04:14:03] <raster> i guess
  • [04:14:09] <raster> thats all i've played with
  • [04:14:14] <raster> thats the one in the galaxy s
  • [04:14:21] <raster> also in the wave too
  • [04:14:23] * chainsawbike (~chainsawb@202-0-50-230.cable.telstraclear.net) Quit (Ping timeout: 276 seconds)
  • [04:14:23] * chainsawbike_ is now known as chainsawbike
  • [04:14:30] <raster> (public info)
  • [04:15:42] <raster> the omap4 tho - that smells like a new ballgame
  • [04:15:50] <raster> and the omap 3440 and 36xx might yet be different
  • [04:15:52] <CruNcher> so both c100 and c110 have the SGX 540 core ?
  • [04:16:05] <raster> i havent had a chance to kick them into action
  • [04:16:12] <raster> i dont know about the c100
  • [04:16:14] <CruNcher> yeah even th 3460 is
  • [04:16:23] <raster> google will probably have info if u dig :)
  • [04:16:52] <raster> personally - i dont much care. i just want a good soc with lots of grunt
  • [04:17:27] <raster> and a gpu with a metric-tonne of pixels/sec throughput (screw triangles/s - talk to me in pixels/s)
  • [04:17:38] <raster> an open gpu is even better (open drivers)
  • [04:22:08] <CruNcher> yeah understandable
  • [04:22:39] <raster> these days most non-gpu bits are open (ie have open drivers in the kernel) - most i say. not all
  • [04:22:45] <raster> so its the gpu thats left as the last bastion
  • [04:25:27] <CruNcher> yup ATI did a nice task opening a part of that world :P though Nvidia is still more succesfull even on GNU/Linux
  • [04:27:06] <raster> because open crap is still ccrap
  • [04:27:11] <raster> :)
  • [04:28:13] <CruNcher> hehe true and ATI doesn't make good news when it goes about their Drivers
  • [04:28:44] <CruNcher> compared to Nvidia even if they have the more powerfull architecture
  • [04:29:06] <CruNcher> sad thing
  • [04:29:10] <raster> well the open drivers dont support this radeon here
  • [04:29:24] <raster> and the fglrx closed ones are utter bunk compared to nvidia's drivers
  • [04:29:27] <raster> so i'd call that crap
  • [04:30:54] <CruNcher> i mean they have the better architecture in sense of the GPU lower energy and better speed, lower price
  • [04:31:53] <raster> sure
  • [04:31:55] <CruNcher> but they dont have a such excelent dev ecosystem and driver team that Nvidia has
  • [04:32:03] <raster> but thats irrelevant if u cant get it to work better
  • [04:32:07] <raster> :)
  • [04:32:19] <raster> ie drivers
  • [04:32:57] <CruNcher> yeah especialy in their master field ATI was known for years they have been hit badly by Nvidia (Video)
  • [04:33:07] <raster> yup
  • [04:33:22] <raster> oh well
  • [04:33:31] <raster> time to go off and do my sunday poo
  • [04:33:37] <CruNcher> therfore though Nvidia lost in 3D ;)
  • [04:33:39] <raster> real life calls
  • [04:33:45] * raster (~raster@enlightenment/developer/raster) Quit (Quit: Gettin' stinky!)
  • [04:33:57] <CruNcher> yeah night and thx for the c100 info
  • [04:34:44] * Zoxc (~zoxc@ti0128a340-dhcp0372.bb.online.no) Quit ()
  • [04:52:49] * Redb3ard (~SF0010MAC@75.110.202.83) has joined #beagle
  • [05:01:36] * Crazymik3 (~Crazymik3@CPE00259c601d5d-CM00080da43848.cpe.net.cable.rogers.com) has joined #beagle
  • [05:04:33] * Mike__ (~Crazymik3@CPE00259c601d5d-CM00080da43848.cpe.net.cable.rogers.com) Quit (Ping timeout: 240 seconds)
  • [05:07:40] * _chase_ (~chase@nat/ti/x-jeoqffyqjvsjxrlz) Quit (Remote host closed the connection)
  • [05:07:57] * _chase_ (~chase@nat/ti/x-dabcdyzcdrjpslws) has joined #beagle
  • [05:13:57] * loko_ (bd1bf292@gateway/web/freenode/ip.189.27.242.146) has joined #beagle
  • [05:14:09] * loko_ (bd1bf292@gateway/web/freenode/ip.189.27.242.146) Quit (Client Quit)
  • [05:17:15] * JDuke128 (~kadir@81.214.22.138) Quit (Ping timeout: 265 seconds)
  • [05:20:10] * jrmuizel (~jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) has joined #beagle
  • [05:31:34] * gdm (~gdm@190.55.34.222) Quit (Ping timeout: 264 seconds)
  • [05:32:38] * scrp3l (~scrp3l@201.250.186.175) has joined #beagle
  • [05:42:12] * hvontres|home (~hvontres@adsl-75-18-112-72.dsl.sndg02.sbcglobal.net) has joined #beagle
  • [05:42:40] * scrp3l (~scrp3l@201.250.186.175) Quit (Remote host closed the connection)
  • [06:13:15] * killring (~killring@76.226.203.45) has joined #beagle
  • [06:17:39] * _chase_ (~chase@nat/ti/x-dabcdyzcdrjpslws) Quit (Remote host closed the connection)
  • [06:17:57] * _chase_ (~chase@nat/ti/x-mmveulcbhlabftvp) has joined #beagle
  • [06:19:33] * hieuletrung (~hieuletru@58.186.139.248) has joined #beagle
  • [06:20:30] * hvontres|home (~hvontres@adsl-75-18-112-72.dsl.sndg02.sbcglobal.net) Quit (Quit: leaving)
  • [06:22:14] * Redb3ard (~SF0010MAC@75.110.202.83) Quit (Quit: Redb3ard)
  • [06:24:11] * emeb|mac (~ericb@ip72-223-81-194.ph.ph.cox.net) Quit (Ping timeout: 260 seconds)
  • [06:30:02] * DanaG (~dana@66-169-236-186.static.snlo.ca.charter.com) has joined #beagle
  • [06:31:12] * DanaG1 (~dana@66-169-236-186.static.snlo.ca.charter.com) has joined #beagle
  • [06:31:12] * DanaG (~dana@66-169-236-186.static.snlo.ca.charter.com) Quit (Disconnected by services)
  • [06:32:11] * Entasis (~Jarred@ppp118-210-194-202.lns20.adl6.internode.on.net) has joined #beagle
  • [06:35:17] * jrmuizel (~jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) Quit (Quit: jrmuizel)
  • [06:37:40] * DanaG (~dana@66-169-236-186.static.snlo.ca.charter.com) has joined #beagle
  • [06:38:41] * DanaG1 (~dana@66-169-236-186.static.snlo.ca.charter.com) Quit (Ping timeout: 276 seconds)
  • [06:38:43] * DanaG (~dana@66-169-236-186.static.snlo.ca.charter.com) Quit (Client Quit)
  • [06:38:58] * DanaG (~dana@66-169-236-186.static.snlo.ca.charter.com) has joined #beagle
  • [06:39:06] * DanaG (~dana@66-169-236-186.static.snlo.ca.charter.com) has left #beagle
  • [06:40:00] * kmargar (~markos@athedsl-426106.home.otenet.gr) has joined #beagle
  • [06:42:51] * markos_ (~markos@athedsl-420550.home.otenet.gr) Quit (Ping timeout: 260 seconds)
  • [06:49:06] * eFfeM (~frans@j200125.upc-j.chello.nl) has joined #beagle
  • [06:54:31] * calculus (~calculus@gentoo/user/calculus) Quit (Ping timeout: 276 seconds)
  • [06:57:10] * hieuletrung (~hieuletru@58.186.139.248) Quit (Quit: Leaving)
  • [07:03:04] * kmargar is now known as markos_
  • [07:04:03] * killring (~killring@76.226.203.45) Quit (Ping timeout: 265 seconds)
  • [07:16:03] * negril (~negril@fsr.e-technik.uni-rostock.de) Quit (Ping timeout: 252 seconds)
  • [07:16:05] * negril (~negril@fsr.e-technik.uni-rostock.de) has joined #beagle
  • [07:20:17] <ds2> wheeeeeee 7" LCD is working
  • [07:20:46] * eFfeM (~frans@j200125.upc-j.chello.nl) Quit (Quit: Leaving.)
  • [07:24:21] <bkero> USB or DVI?
  • [07:24:29] <ds2> neither
  • [07:24:44] <bkero> LVDS? VGA? Component?
  • [07:24:52] <ds2> parallel
  • [07:24:54] <bkero> Coaxial? GPIO?
  • [07:24:57] <bkero> Ah
  • [07:26:06] <ds2> i wish someone made some 7" VGA LCDs
  • [07:26:18] <bkero> Uhh...I have one
  • [07:26:27] <bkero> They most definitely do, they're made for Car PCs
  • [07:26:34] <bkero> They're even touchscreens
  • [07:29:49] <ds2> hmmm, I need to look in that area... wanted one for a CNC machine control
  • [07:29:59] <ogra> ds2, http://cgi.ebay.de/7-TFT-LCD-Monitor-TOUCHSCREEN-f%fcr-Auto-KFZ-CAR-PC-VGA_W0QQitemZ350312742006QQcmdZViewItem?rvr_id=&rvr_id=&cguid=da6e8bb71250a0aad4a154d1fa24a48e#ht_4919wt_1138 (sorry, german, but i bet someone sells them in your country too)
  • [07:30:22] <ogra> (VGA with usb touchscreen)
  • [07:30:35] <ds2> then again, it is easier to fit a beagle to the application
  • [07:30:42] <_av500_> but no dvi on this one
  • [07:30:48] <ogra> sadly
  • [07:30:50] <bkero> Yea. VGA is beagle's archnemesis.
  • [07:31:02] <ds2> VGA on the beagle is easy
  • [07:31:05] <bkero> As soon as I can get a good pair of DVI glasses...
  • [07:31:11] <ds2> question is why
  • [07:31:19] <bkero> Wearable computer
  • [07:31:27] <bkero> All display glasses are shitty VGA things
  • [07:31:44] <_av500_> dvi does not make them better
  • [07:31:52] <_av500_> higher res would
  • [07:31:53] <ds2> hmmm, you must be rich ;) the VGA glasses are all $$$$$$, the ones I can find are all composite
  • [07:32:00] * dm8tbr would happily go with 800x600 glasses
  • [07:32:11] <dm8tbr> but last time I checked good ones were ????????????
  • [07:32:44] <dm8tbr> composite with low-res lcd are cheap
  • [07:32:47] <bkero> DVI would make them interface with the beagle without additional hardware
  • [07:33:00] <bkero> ds2: Not rich, the glasses are ~$150-200
  • [07:33:06] <ds2> same with composite (passive converter)
  • [07:33:12] <_av500_> dm8tbr: i guess a dual iphone4 glasses holder would be awesome
  • [07:33:14] <bkero> and I could probably get my university to bankroll it if I posed an interesting enough interface
  • [07:33:18] <_av500_> retina to retina
  • [07:33:26] <dm8tbr> _av500_: aaaah, the mental image...
  • [07:33:32] <ds2> bkero: I must be shopping at the wrong place. who has VGA (640x480 or better) glasses for under $200?
  • [07:33:57] <dm8tbr> the all new iHolder - beauty lies in the eye of the apple-holder
  • [07:34:42] <bkero> ds2: It's been a while since I've priced them
  • [07:35:28] * maluta (~maluta@189.107.26.214) Quit (Ping timeout: 265 seconds)
  • [07:36:54] <bkero> I think I was looking at either i-Glasses or Vuzix Wrap's
  • [07:37:02] * maluta (~maluta@189.107.0.180) has joined #beagle
  • [07:37:17] * _courville_ (~marc@courville.org) has joined #beagle
  • [07:39:30] * CruNcher (~luls_lol@188.107.70.4) Quit ()
  • [07:39:35] * CruNcher (~luls_lol@188.107.70.4) has joined #beagle
  • [07:50:01] <ds2> 800x480 is so much nicer then 480x272 ;)
  • [07:50:07] * ogra (~ogra@ubuntu/member/ogra) Quit (Read error: Connection reset by peer)
  • [07:52:07] * ogra (~ogra@ubuntu/member/ogra) has joined #beagle
  • [07:56:02] * thaytan (~jan@ppp59-167-167-201.static.internode.on.net) has joined #beagle
  • [07:59:42] <_av500_> exactly 2.94x nicer
  • [08:01:39] * raster (~raster@enlightenment/developer/raster) has joined #beagle
  • [08:12:26] * mobidev (~mobidev@94.127.205.30) has joined #beagle
  • [08:14:23] * t_s_o (~tso@183.84-49-135.nextgentel.com) has joined #beagle
  • [08:21:09] * mobidev (~mobidev@94.127.205.30) Quit (Quit: I go offline...)
  • [08:33:03] <koen> "I have no relationship with Google and the did not pay me to make their stuff awesome (so it is not awesome). "
  • [08:33:06] <koen> heh
  • [08:33:11] <koen> from http://www.tester.ca/2010/06/26/n900-vs-nexus-one-a-comparison/
  • [08:38:33] * bearsh_ (~quassel@adsl-245-48-fixip.datacomm.ch) Quit (Read error: Network is unreachable)
  • [08:40:03] * bearsh (~quassel@adsl-245-48-fixip.datacomm.ch) has joined #beagle
  • [08:40:18] * drinkcat (~nicolas@181-162.4-85.cust.bluewin.ch) has joined #beagle
  • [08:48:49] <raster> koen: hoi
  • [08:49:02] <koen> hey raster
  • [08:49:22] <koen> raster: any chance those neon bits get put in .S files so gcc won't mess them up?
  • [08:49:42] <raster> koen: the neon evas bugs are almost definitely toolchain (compiler bugs)
  • [08:49:59] <raster> all i can suggest is seeing what codesourcery have patched their 4.4.1 gcc toolchain wtih to fix it
  • [08:50:02] <raster> probably q clobbering
  • [08:50:16] <raster> no chnace
  • [08:50:31] <raster> u need to handle register clobbering no matter what
  • [08:50:34] <raster> as u go in and out of c
  • [08:51:14] <raster> so c needs to know which neon registers have been used by the asm
  • [08:51:48] <raster> in case the compiler optimises the regular c with neon
  • [08:51:51] <raster> and uses the regs
  • [08:52:38] <raster> so.... can do all sorts of ugly hacks like save and restore all neon q regs - or all the used ones every time u enter and exit some asm
  • [08:52:57] <raster> but thats doing the compilers job for it
  • [08:52:59] <koen> sadly 4.4.x is sooo slow on arm
  • [08:53:02] <raster> it can perfectly well do this itself
  • [08:53:04] <raster> but it doesnt
  • [08:53:14] <raster> well it might not even be in mainline
  • [08:53:21] <raster> its likely codesourcery patches
  • [08:53:51] <raster> but from what i gather of the issue right now - its certainly a compiler bug
  • [08:54:05] <raster> i loathe the idea of working around compiler bugs in src
  • [08:54:29] <koen> it's funny that evas is the first app to trigger that bug, while other neon using apps work fine...
  • [08:54:39] <raster> especially as at least 1 gcc version out there has it already fixed
  • [08:55:04] <koen> my experience is that the csl stuff is usually buggy and people start relying on those bugs
  • [08:55:05] <raster> may be wrong
  • [08:55:18] <raster> nash will poke around and see what he can do
  • [08:55:26] <koen> great, thanks
  • [08:55:39] <koen> he can get a toolchain from http://www.angstrom-distribution.org/toolchains/
  • [08:56:01] <koen> I bet nash is mature enough to ignore the qt bits inside that :)
  • [08:56:11] * ppoudel (~chatzilla@129.114.246.141) Quit (Quit: ChatZilla 0.9.86 [Firefox 3.0.17/2010010604])
  • [08:56:17] <raster> do a test to make sure that this is the case
  • [08:56:55] <koen> raster: e17 got lots of press with the liquidware stuff, did you notice?
  • [08:56:58] * lucent (lucent@unaffiliated/shadows) has joined #beagle
  • [08:57:06] <raster> buty this is ghe best guess right now
  • [08:57:08] * lucent reads topic
  • [08:57:16] <raster> liquidware?
  • [08:57:18] <raster> nup
  • [08:57:19] <raster> didnt notice
  • [08:57:25] <raster> but i've been out of it
  • [08:57:38] <lucent> looking for suitability of BeagleBoard xM with a JAVA-based Point of Sale app, it needs "javadb" (a.k.a. Derby)
  • [08:58:12] <lucent> research thus far indicates that I should look at IcedTea / OpenJDK
  • [08:58:15] <koen> raster: http://www.liquidware.com/shop/show/BB-BT/BeagleTouch
  • [08:58:22] <lucent> anyone play with JAVA much on the BB?
  • [08:58:28] <koen> raster: check the pictures, the bottom one got used in lots of articles
  • [08:58:55] <koen> angstrom has support for that openjdk stuff
  • [08:58:59] <koen> but I never used it
  • [08:59:05] <lucent> ah, good to know though
  • [08:59:28] <koen> java is just a waste of cpu cycles on arm, no matter how fast the java people make their vm/jit
  • [08:59:53] <raster> koen: hahahahhaha
  • [08:59:57] <raster> funny. osx wallpaper
  • [08:59:58] <raster> :)
  • [09:00:25] <lucent> I'm looking at point of sale though, so it comes down to how much electricity does thing eat vs. how much does software cost
  • [09:00:26] <raster> oooh its that "turn bb into tablet" addon
  • [09:01:00] <lucent> have found an open licensed pos software which would do the trick, next am researching what hardware it would run on
  • [09:03:19] <lucent> koen: if I want to explore this myself on an x86 system, what would be available to me on the BB package-wise, where would I start?
  • [09:24:35] <lucent> actually... I don't need Derby, I can use a number of databases. Should be excellent.
  • [09:34:16] * hgs (~hgs@82.202-63-132.static.qala.com.sg) has joined #beagle
  • [09:53:35] * khasim (~a0393720@192.163.20.231) Quit (Ping timeout: 260 seconds)
  • [09:55:59] * Ceriand|desktop (~Ceriand@unaffiliated/ceriand) Quit (Read error: Connection reset by peer)
  • [10:55:12] * Ceriand|work (~Ceriand@unaffiliated/ceriand) Quit (Remote host closed the connection)
  • [10:58:57] * Ceriand|work (~Ceriand@pc41.cs.ucdavis.edu) has joined #beagle
  • [10:58:59] * Ceriand|work (~Ceriand@pc41.cs.ucdavis.edu) Quit (Changing host)
  • [10:58:59] * Ceriand|work (~Ceriand@unaffiliated/ceriand) has joined #beagle
  • [11:12:18] <ssvb> raster: this clobber issue can be easily workarounded, just replace "q0" with "d0", "d1", "q1" with "d2", "d3" and so on in your clobber list, as an additional bonus it will work with all the buggy legacy toolchains
  • [11:13:03] <raster> ssvb: but thats actually incorrect
  • [11:13:22] <ssvb> raster: why do you think so?
  • [11:13:37] <raster> sure - it's a workaround - it's sneaking past some known logic
  • [11:13:44] <raster> rathewr than doing it right
  • [11:13:58] <raster> what *IF* q and d become separate regs some time in a future neon arch?
  • [11:14:53] * rsalveti (~rsalveti@201.82.71.207) Quit (Ping timeout: 260 seconds)
  • [11:14:54] <ssvb> raster: lol, this is never going to happen without a major compatibility break
  • [11:15:06] <raster> it is almost always a bad move to work around buggy compilers - as sooner or later your "workarounds" come back to bite you in the arse when its fixed
  • [11:15:07] <raster> :)
  • [11:17:09] <mru> q and d becoming distinct in the future is exceedingly unlikely
  • [11:17:26] <mru> and if they did, it won't matter for this, since no old code would work anyway
  • [11:17:52] <raster> sure - changing them to not overlap would change a lot of assaumptions - but its still conceptially wrong :)
  • [11:18:07] <mru> not really
  • [11:18:21] <mru> the broken q in clobber lists is an annoying bug, nothing else
  • [11:18:44] <mru> as long as you tell the compiler exactly what is clobbered, the code is correct
  • [11:18:45] <raster> then why is gcc so stupid when it sees a clobber for q0 it doesnt instantly convert that to t0, d1 itself?
  • [11:18:54] <raster> tyhis isnt something imho you should work around
  • [11:18:55] <ssvb> raster: all the compilers have bugs without exceptions (they are too complex), avoiding known bugs is just a normal practical solution
  • [11:19:04] <mru> raster: because gcc is just that stupid
  • [11:19:04] <raster> you use q0, the clobber a0 - not d0, d1
  • [11:19:05] <raster> :)
  • [11:19:23] <raster> ssvb: yeah, but this isnt a complex thing
  • [11:19:34] <raster> its like a cpu not being ABLE TO ADD 3+4
  • [11:19:50] <raster> its broken in gcc - it should be fixed in gcc
  • [11:19:50] <raster> :)
  • [11:19:58] <ssvb> raster: check gcc bugzilla - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43440
  • [11:19:59] <mru> the gcc "design" makes it very hard to do this conversion
  • [11:20:01] <raster> unliek a cpu - gcc can be fixed and updated easily :)
  • [11:20:14] <raster> mru: seems codesourcery managed it
  • [11:20:36] <mru> maybe they tried very hard
  • [11:21:07] <ssvb> raster: they even have two patches for this, but did not particularly hurry to apply them, maybe because they don't see this problem as an important issue
  • [11:21:32] <mru> the proper solution is of course to not use inline asm in the first place
  • [11:21:37] <ssvb> raster: you can try this one - http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00978.html
  • [11:21:46] <mru> you'll get faster code as a bonus
  • [11:22:14] <ssvb> mru: that's not a proper solution and not always faster
  • [11:22:27] <mru> keeping gcc out of the loop is always good
  • [11:22:35] <ssvb> mru: it's just an alternative of many
  • [11:22:36] <raster> ssvb: don't worry about us - we already have a patched and working gcc
  • [11:22:47] <raster> ssvb: its not a problem here. it's a problem for others like koen
  • [11:22:56] <raster> their gcc is broken beingh unable to clobber used regs
  • [11:23:25] <ssvb> raster: well, it's also obviously a problem for you
  • [11:23:28] <mru> inline asm was never intended for huge swaths of code
  • [11:23:32] <mru> and it shows
  • [11:23:50] <raster> ssvb: not really. my customer has a working gcc toolchain and fast rendering. they're happy :)
  • [11:24:46] <koen> ssvb: about http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00978.html , I didn't know people were still using non-unified diffs (except dm8tbr)
  • [11:25:22] * dm8tbr blinks
  • [11:25:36] <mru> eeek
  • [11:25:44] <ssvb> I guess we just need to bump this gcc bug and ask there what kind of patch was applied for codesourcery
  • [11:25:51] * dm8tbr intends to master git ASAP
  • [11:26:07] * mru remembers asking the faad devs to switch their commit mails to unified diffs once upon a time
  • [11:26:15] <mru> they replied that they preferred unreadable ones
  • [11:26:22] <ssvb> again, this problem is not perceived as important by upstream gcc developers, maybe because not many people complain
  • [11:27:30] <ssvb> raster: feel free to add yourself to CC for that gcc bug and maybe add a comment describing how it affects you
  • [11:27:58] <raster> i just don't like the idea of twisting and swizzling code to work around bugs in a compiler - that at least have known fixes for already :)
  • [11:28:17] <mru> nor do I
  • [11:28:47] <raster> if this was a really tricky corner case inside optimisation logic with no fix in sight... i'd consider it differently
  • [11:29:01] <raster> i'm even considering hacking around it anyway - but it just feels unclean
  • [11:29:02] <raster> :)
  • [11:29:25] <ssvb> raster: do you have safety #ifdefs in your code preventing compilation with known buggy versions of compilers?
  • [11:29:57] <raster> no
  • [11:30:05] <raster> as this bug was only reported recently
  • [11:30:15] <mru> btw is there a good way to identify the compiler as being "genuine" gcc and not something else running in compatibility mode?
  • [11:30:18] <ssvb> raster: well, you are just kind of sticking your head in the sand :)
  • [11:30:19] <raster> didnt know even what it was and it's not 100% confirmed yet
  • [11:30:31] <raster> but high suspicion (lets say 90%) is the clobbering of q regs
  • [11:30:37] <koen> mru: instead of authentic arm?
  • [11:30:47] <ssvb> raster: because it is a *known* problem, and you actually can *do* something about it
  • [11:31:10] <mru> koen: or True TI
  • [11:31:23] <raster> right now i dont even know if it is possibnle to detect a buggy gcc ver
  • [11:31:52] <mru> there are predefined macros for gcc version
  • [11:32:03] <mru> but things like EDG define those too
  • [11:32:16] <raster> mru: sure - but this is a 4.4.1 WITH codesourcery patches
  • [11:32:21] <ssvb> raster: just get rid of q-registers in the clobber list and everyone will be happy :)
  • [11:33:03] <raster> ssvb: i cant do anything about it currently
  • [11:33:19] <raster> i dont have a working toolchain myself
  • [11:33:25] <raster> mind is rotally broken for neon
  • [11:33:27] <raster> mine
  • [11:33:49] <raster> nash has the fixed gcc so doesnt see the issue
  • [11:34:09] <raster> so it'll have to wait
  • [11:34:11] <ssvb> koen: actually distro maintainers can make a simple script to scan for this potential issue in the sources
  • [11:34:23] <raster> as such the bug happens if u --enable-cpu-neon in configure
  • [11:34:28] <ssvb> koen: and patch the sources if upstream does not want to
  • [11:34:48] <koen> right
  • [11:34:48] <raster> so already the bug doesnt happoen by default - it happens if the persopn building explicitly asks for neon optimised asm code
  • [11:35:10] <koen> so you have one working toolchain, which isn't gcc
  • [11:35:29] <raster> so there's a very quick fix "dont use it until its fixed - your gcc or src works around it"
  • [11:35:47] <raster> koen: well its gcc... just with patches
  • [11:35:48] <raster> :)
  • [11:35:57] * mru prefers the ffmpeg way
  • [11:36:19] <raster> still need to prove that it is this problem first
  • [11:39:06] <koen> ssvb: that patch doesn't apply to gcc 4.3.x, that is missing reginfo.c
  • [11:39:35] <koen> I guess I need to start poking TI harder to fix the codec-engine problems with recent binutils
  • [11:41:38] <ssvb> mru: fortunately ffmpeg is a lot more simple than gcc and most things are reasonably easy to fix (probably except for ogg demuxer)
  • [11:42:39] <ssvb> mru: "simple" not in a bad sense
  • [11:44:23] <mru> I meant the ffmpeg approach to dealing with broken compilers
  • [11:44:38] <mru> and do not speak to me about the ogg demuxer
  • [11:49:07] <ssvb> mru: well, but you do speak about broken compilers, so what's wrong with broken demuxers? there is just no perfect software
  • [11:49:22] <mru> I never made that implication
  • [11:49:38] <mru> we were talking about how to deal with broken compilers when writing software
  • [11:50:30] <ssvb> mru: and one of the fist things is to report bugs upstream, right?
  • [11:50:40] <mru> yes
  • [11:51:15] <mru> so?
  • [11:51:33] <mru> until it (possibly) gets fixed, you still need to do something
  • [11:52:03] <ssvb> so if raster is interested in getting it eventually fixed, I think it may help to bump this gcc bug (with additional details)
  • [11:52:19] <mru> I never said that was a bad idea
  • [11:52:34] <raster> ssvb: it'd be nice to be fixed
  • [11:52:47] <raster> as i said - i woudl consider a workaround too
  • [11:52:57] <mru> this particular bug is easy to work around without any negative side-effects
  • [11:53:05] <ssvb> another thing is to be able to detect bugs which affect you - automated test suites are important
  • [11:53:09] <raster> but i have to go through all the initial steps of verifying it actually is the bug it ia thought to be first
  • [11:53:13] <ssvb> that's pretty simple too
  • [11:53:19] <raster> and then verifying a workaround fixes it before comiitting
  • [11:53:21] <mru> a workaround making code slower should be treated with utmost caution
  • [11:53:30] <ssvb> slower?
  • [11:53:48] <mru> suppose you hit a compiler bug
  • [11:54:11] <mru> suppose someone proposes a workaround that changes the code in a way that makes it slower than it would be if the compiler worked with the original
  • [11:54:41] <mru> if you accept that, you'll have suboptimal code when the bug is fixed
  • [11:54:50] <mru> and you probably will forget about it and never notice
  • [11:55:29] <raster> mru: correct - as a general thing i'd prefer a bug and wait for gcc to be fixed
  • [11:55:43] <raster> buty in this case clobber d0,d1 instead of q0 is a no-loss fix
  • [11:55:47] <raster> but imho unclean
  • [11:55:47] <mru> sometimes it's possible to detect the bug in a configure script
  • [11:55:57] <mru> and deploy the workaround only when strictly necessary
  • [11:56:15] <mru> the q/d thing is purely stylistic
  • [11:56:23] <raster> mru: cross-comp :(
  • [11:56:34] <mru> I said sometimes
  • [11:56:40] <mru> as in failure to compile at all
  • [12:08:46] * JDuke128 (~kadir@81.214.22.138) has joined #beagle
  • [12:14:09] * naeg (~naeg@194.208.239.170) has joined #beagle
  • [12:26:24] * calculus (~calculus@gentoo/user/calculus) has joined #beagle
  • [12:27:15] * Dead1nside (~Dead1nsid@78.86.212.180) Quit (Ping timeout: 240 seconds)
  • [12:32:14] * jrmuizel (~jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) has joined #beagle
  • [12:54:47] * jrmuizel (~jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) Quit (Quit: jrmuizel)
  • [12:56:15] * CruNcher (~luls_lol@188.107.70.4) Quit (Ping timeout: 240 seconds)
  • [13:03:49] * RobotGrrl (~RobotGrrl@bas2-montreal50-2925252324.dsl.bell.ca) has joined #beagle
  • [13:06:24] * naeg (~naeg@194.208.239.170) Quit (Ping timeout: 252 seconds)
  • [13:20:35] * maluta (~maluta@189.107.0.180) Quit (Quit: leaving)
  • [13:22:10] * mgalemin (~mgalemin@r220-101-20-165.cpe.unwired.net.au) has joined #beagle
  • [13:27:16] * mgalemin (~mgalemin@r220-101-20-165.cpe.unwired.net.au) has left #beagle
  • [13:27:44] * jrmuizel (~jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) has joined #beagle
  • [13:30:05] * mgalemin (~mgalemin@r220-101-20-165.cpe.unwired.net.au) has joined #beagle
  • [13:30:31] * mgalemin (~mgalemin@r220-101-20-165.cpe.unwired.net.au) has left #beagle
  • [13:36:50] * RobotGrrl (~RobotGrrl@bas2-montreal50-2925252324.dsl.bell.ca) Quit (Quit: RobotGrrl)
  • [13:37:16] * scrp3l (~scrp3l@201.250.186.175) has joined #beagle
  • [13:37:24] * emeb|mac (~ericb@ip72-223-81-194.ph.ph.cox.net) has joined #beagle
  • [13:39:28] <buZz> cool, scored an armv5te device (zaurus sl-c1000)
  • [13:41:24] * rsalveti (~rsalveti@187.42.255.211) has joined #beagle
  • [13:44:49] * markc (~markc@60-240-81-28.static.tpgi.com.au) has joined #beagle
  • [13:46:22] <markc> howdy, just in the process of trying to install x-loader/u-bootand I think I'm at step 5: Wait for Flashing to end, how do I tell when the flashing has ended?
  • [13:46:30] * hgs (~hgs@82.202-63-132.static.qala.com.sg) has left #beagle
  • [13:48:42] <markc> ioc, do I *have* to have a monitor connected?
  • [13:51:24] * rcranetx (~rcranetx@nat/ti/x-eblmevmpgbcufdzg) has joined #beagle
  • [13:52:24] <_av500_> no
  • [13:52:44] <koen> to your computer, yes, to your beagle, no
  • [13:52:52] <_av500_> monitor just distracts you from the serial console...
  • [13:54:09] * eFfeM (~frans@j200125.upc-j.chello.nl) has joined #beagle
  • [13:54:25] <markc> I have had minicom -D /dev/ttyACM0 working, but not as it boots up, how do I tell when or iof the flashing procedure has finished?
  • [13:55:20] <markc> or, are there better instructions than this? ->http://elinux.org/BeagleBoardUbuntu#Upgrade_X-loader_and_U-boot
  • [13:55:33] <markc> I just want to get any OS onto an SD card
  • [13:55:38] <koen> I use http://dominion.thruhere.net/koen/OE/uboot-flash.cmd.scr as boot.scr to flash nand
  • [13:56:57] <markc> so can I just overwrite that onto my SD card as boot.scr?
  • [13:57:17] <_av500_> markc: u dont need to flash anything to get an os onto the sd card...
  • [13:59:32] <markc> so if I follow this I should be right? -> http://elinux.org/BeagleBoardUbuntu#Lucid_10.04
  • [14:12:32] * raster (~raster@enlightenment/developer/raster) Quit (Quit: Gettin' stinky!)
  • [14:19:26] * arunjoseph (~arun@192.163.20.231) Quit (Remote host closed the connection)
  • [14:20:28] * arunjoseph (~arun@192.163.20.231) has joined #beagle
  • [14:21:42] <markc> looks like I have ubuntu on my SD card, when I turn of the power how do I get it to boot the card? run bootmmc or something?
  • [14:22:34] <jacekowski> have you considered reading the manual?
  • [14:23:12] * gdm (~gdm@190.55.34.222) has joined #beagle
  • [14:24:30] <markc> jacekowski: I would like to... where or which one?
  • [14:24:47] <jacekowski> http://elinux.org/BeagleBoard
  • [14:24:50] <jacekowski> here for example
  • [14:24:56] <markc> I have flashing lights on the board so I guess it's booting from the card
  • [14:25:12] <jacekowski> get a serial cable
  • [14:25:20] * emeb|mac (~ericb@ip72-223-81-194.ph.ph.cox.net) Quit (Ping timeout: 265 seconds)
  • [14:26:26] <koen> mru: I ran IVA at 1GHz successfully, but as you say, no idea if all 37xx will tolerate that (and for how long)
  • [14:26:57] <koen> [ 0.000000] OMAP3630/DM3730 ES1.0 (l2cache iva sgx neon isp 192mhz_clk )
  • [14:27:14] <koen> hmmm, I have an ES1.1, guess the kernel doesn't know about that one yet :)
  • [14:27:45] * rsalveti (~rsalveti@187.42.255.211) Quit (Ping timeout: 265 seconds)
  • [14:27:46] <koen> av500: btw, svideo is working on xM as well, it was a hw problem
  • [14:28:07] * Sept (~bakljg@c-24-131-138-21.hsd1.mn.comcast.net) has joined #beagle
  • [14:28:17] <koen> av500: the 37xx has a C + R internally, while the 35xx only has R, so after removing a cap from the board it started working
  • [14:28:37] <koen> or something like that
  • [14:28:45] * koen didn't pay too much attention to that topic
  • [14:30:26] * rcranetx (~rcranetx@nat/ti/x-eblmevmpgbcufdzg) Quit (Quit: Leaving.)
  • [14:30:49] * Septalici (~bakljg@c-24-131-138-21.hsd1.mn.comcast.net) Quit (Ping timeout: 276 seconds)
  • [14:32:44] * emeb (~ericb@ip72-223-81-194.ph.ph.cox.net) has joined #beagle
  • [14:39:07] * emeb is now known as emeb|mac
  • [14:40:04] * emeb|mac is now known as emeb-eee
  • [14:40:34] * emeb-eee is now known as emeb
  • [14:45:34] * Zoxc (~zoxc@ti0128a340-dhcp0372.bb.online.no) has joined #beagle
  • [14:49:33] * mpoirier (~quassel@S0106002369de4dac.cg.shawcable.net) has joined #beagle
  • [15:05:40] * markc (~markc@60-240-81-28.static.tpgi.com.au) Quit (Remote host closed the connection)
  • [15:10:13] * scrp3l (~scrp3l@201.250.186.175) Quit (Ping timeout: 264 seconds)
  • [15:21:25] * mobidev (~mobidev@94.127.205.30) has joined #beagle
  • [15:21:41] * espindola (~espindola@CPE001a704e2b6d-CM001225dd5348.cpe.net.cable.rogers.com) has joined #beagle
  • [15:27:23] * espindola (~espindola@CPE001a704e2b6d-CM001225dd5348.cpe.net.cable.rogers.com) Quit (Quit: Ex-Chat)
  • [15:31:09] * Meizirkki (~Meizirkki@YYYKMDCCCXLIII.gprs.sl-laajakaista.fi) has joined #beagle
  • [15:31:10] * topfs2 (~topfs2@xbmc/staff/topfs2) has joined #beagle
  • [15:34:13] * Redb3ard (~SF0010MAC@75.110.202.83) has joined #beagle
  • [15:37:15] * aszpain (~fuldrul@244.67.18.95.dynamic.jazztel.es) has joined #beagle
  • [15:39:22] * CruNcher (~luls_lol@188.107.70.4) has joined #beagle
  • [15:39:58] * t_s_o (~tso@183.84-49-135.nextgentel.com) Quit (Remote host closed the connection)
  • [15:45:23] <aszpain> is there a channel for IGEPv2 discussion?
  • [16:00:55] * Entasis (~Jarred@ppp118-210-194-202.lns20.adl6.internode.on.net) Quit (Quit: Leaving)
  • [16:01:06] * cubass (4cccd3a4@gateway/web/freenode/ip.76.204.211.164) has joined #beagle
  • [16:02:51] <aszpain> where is the pandaboard omap4 web page? cannont find it in google
  • [16:03:23] * Crazymik3 (~Crazymik3@CPE00259c601d5d-CM00080da43848.cpe.net.cable.rogers.com) Quit (Quit: Leaving)
  • [16:03:33] * Mike (~Crazymik3@CPE00259c601d5d-CM00080da43848.cpe.net.cable.rogers.com) has joined #beagle
  • [16:04:00] * Mike is now known as Guest96440
  • [16:04:59] <koen> aszpain: there's a pandaboard wiki inside the TI intranet :)
  • [16:05:41] <koen> I guess the external would will be at pandaboard.org
  • [16:14:30] * Wiltzy (~mark@76-204-211-164.lightspeed.dllstx.sbcglobal.net) has joined #beagle
  • [16:18:53] * cubass (4cccd3a4@gateway/web/freenode/ip.76.204.211.164) Quit (Quit: Page closed)
  • [16:20:52] <emeb> I keep hearing references to pandaboard but know nothing about it.
  • [16:20:52] * ppoudel (~chatzilla@129.114.246.141) has joined #beagle
  • [16:21:07] <emeb> looks like pandaboard.org is not accessible yet.
  • [16:23:27] * Wiltzy (~mark@76-204-211-164.lightspeed.dllstx.sbcglobal.net) has left #beagle
  • [16:23:38] <koen> it will be a relatively cheap omap4 based board
  • [16:23:47] <koen> no relation to beagleboard.org, though
  • [16:23:57] <emeb> ok - just spotted this: https://wiki.ubuntu.com/Specs/M/ARMSoCOMAP
  • [16:24:14] <emeb> dual-core cortex A9
  • [16:25:00] <emeb> aszpain: yesterday you were giving up on your Beagle C4 due to EHCI issues?
  • [16:25:01] * neo01124 (~neo@122.163.68.5) has joined #beagle
  • [16:31:53] * CuBass (~mark@76-204-211-164.lightspeed.dllstx.sbcglobal.net) has joined #beagle
  • [16:35:52] * CuBass (~mark@76-204-211-164.lightspeed.dllstx.sbcglobal.net) has left #beagle
  • [16:44:29] * neo01124 (~neo@122.163.68.5) Quit (Ping timeout: 240 seconds)
  • [16:50:52] * neo01124 (~neo@122.163.113.75) has joined #beagle
  • [16:57:17] <topfs2> koen, according to your screens it looks like you are missing all textures
  • [16:57:43] <topfs2> http://xbmc.org/skins/confluence/
  • [17:00:57] * Dead1nside (~Dead1nsid@78.86.212.180) has joined #beagle
  • [17:05:23] * emeb (~ericb@ip72-223-81-194.ph.ph.cox.net) Quit (Quit: Leaving.)
  • [17:13:40] <koen> topfs2: could be
  • [17:13:53] <koen> will do a new 'make install' and remove .xbmc
  • [17:14:03] <koen> well, a new build and make install
  • [17:17:11] * Redb3ard (~SF0010MAC@75.110.202.83) Quit (Quit: Redb3ard)
  • [17:25:27] <_av500_> koen: ok (wrt venc)
  • [17:28:31] * Meizirkki (~Meizirkki@YYYKMDCCCXLIII.gprs.sl-laajakaista.fi) Quit (Ping timeout: 265 seconds)
  • [17:29:47] <koen> topfs2: have you tried playing a simple movie?
  • [17:29:54] <topfs2> yup, works
  • [17:29:58] <koen> topfs2: e.g. the 480p bunny?
  • [17:30:09] <topfs2> Not that one, I can try that now though
  • [17:30:40] <koen> I suspect Jefro will want to demo a movie as well, would be nice if we can supply a working one
  • [17:31:38] <koen> topfs2: just to confirm 'make install DESTDIR=foo' is supposed to work, right?
  • [17:31:47] * Redb3ard (~SF0010MAC@75.110.202.83) has joined #beagle
  • [17:31:48] <koen> there isn't some weird xbmc install thing
  • [17:31:59] * KosiNuss (~tom@p4FD12452.dip0.t-ipconnect.de) has joined #beagle
  • [17:32:05] <topfs2> Nope, I doubt that work :(
  • [17:32:18] <topfs2> I use ./configure --prefix=/foo/bar
  • [17:32:26] <topfs2> Have never tested that outher one
  • [17:32:30] <koen> but 'make install' would work, right?
  • [17:32:42] <koen> since the --prefix one hardcodes paths
  • [17:32:59] <koen> well, the one without --prefix does as well, but at least those paths are standard :)
  • [17:33:19] <TheUni> mru: haven't forgotten about the ffmpeg patches
  • [17:33:29] <TheUni> just need to get around to it. busy with other stuff
  • [17:33:35] <koen> wow, that's a long RTT :)
  • [17:34:29] <TheUni> eh?
  • [17:34:46] <koen> didn't mru ask that yesterday?
  • [17:34:58] <koen> topfs2: going to rebase your patches on top of trunk tomorrow?
  • [17:35:06] <TheUni> mru: every time i fetch ffmpeg i get distracted playing with vp8. new bilinear filter is nice :)
  • [17:35:16] <topfs2> koen, I wish I knew but it looks like it uses DESTDIR at most places
  • [17:35:28] <TheUni> koen: yea, i try to be good about checking for hi-lites in backlog
  • [17:35:41] <koen> topfs2: I do make install DESTDIR=${PWD}/foo and then cp over the stuff
  • [17:35:42] * mobidev (~mobidev@94.127.205.30) Quit (Quit: I go offline...)
  • [17:35:50] <topfs2> koen, I hoped to but some of the patches I'm not sure how to fix up "proper" to commit to trunk
  • [17:36:22] <koen> TheUni: almost 40fps: http://www.flickr.com/photos/koenkooi/4736210388/in/photostream/
  • [17:36:31] * lirtex (~liorc@89-138-158-93.bb.netvision.net.il) has joined #beagle
  • [17:37:04] <TheUni> koen: wow, nice. but you're cheating with beefier hw, right?
  • [17:37:07] * neo01123 (~neo@122.163.113.214) has joined #beagle
  • [17:37:51] <lirtex> Hi. Can anyone help me with serial programming on the beagleboard? I'm trying to send a byte to /dev/ttyS1 and nothing seems to happen. I checked the pins in the expansion header, and they dont seem to change even when I cat a long file to the serial device.
  • [17:38:10] <TheUni> koen: if you get a chance, maybe you could make a quick vid? then we could post the talk and a video of the current state together?
  • [17:38:18] <lirtex> Is /dev/ttyS1 the "other" (extension) serial device on the beagleboard?
  • [17:38:27] <topfs2> but koen I can for sure rebase and attach them someplace if you want instead of pushing to trunk imediatly?
  • [17:39:05] * neo01124 (~neo@122.163.113.75) Quit (Ping timeout: 276 seconds)
  • [17:39:29] <lirtex> Should I set it up somehow? I'm not sure what the pin state is or how to change it. I know how to control the gpio pins but this is difference ofcourse.
  • [17:39:39] <koen> TheUni: yes, my girlfriend was away with the cameras this weekend, but she has returned now
  • [17:39:44] * t_s_o (~tso@183.84-49-135.nextgentel.com) has joined #beagle
  • [17:39:56] <TheUni> hehe ok
  • [17:39:56] <koen> topfs2: that'd be nice
  • [17:40:02] * Redb3ard (~SF0010MAC@75.110.202.83) Quit (Quit: Redb3ard)
  • [17:41:32] * arunjoseph (~arun@192.163.20.231) Quit (Remote host closed the connection)
  • [17:41:46] * arunjoseph (~arun@192.163.20.231) has joined #beagle
  • [17:42:40] * KosiNuss_ (~tom@p4FD1016A.dip0.t-ipconnect.de) has joined #beagle
  • [17:43:13] * Artanis (Artanis@159.108.165.83.dynamic.mundo-r.com) Quit (Ping timeout: 264 seconds)
  • [17:43:24] <koen> after dinner it should be finished compiling and I'll make a movie
  • [17:44:18] <topfs2> koen, I'll try doing it tonight but otherwise tommorrow
  • [17:44:21] * Redb3ard (~SF0010MAC@75.110.202.83) has joined #beagle
  • [17:45:17] * neo01123 is now known as neo01124
  • [17:46:14] * KosiNuss (~tom@p4FD12452.dip0.t-ipconnect.de) Quit (Ping timeout: 276 seconds)
  • [17:47:15] * lirtex (~liorc@89-138-158-93.bb.netvision.net.il) Quit (Remote host closed the connection)
  • [17:47:34] * lirtex (~liorc@89-138-158-93.bb.netvision.net.il) has joined #beagle
  • [17:49:13] * Redb3ard (~SF0010MAC@75.110.202.83) Quit (Ping timeout: 260 seconds)
  • [17:53:11] * theholyduck (~holyduck@77.106.157.78) has joined #beagle
  • [18:10:48] * Artanis (Artanis@159.108.165.83.dynamic.mundo-r.com) has joined #beagle
  • [18:22:11] * ckrinke (~IceChat7@76-218-61-186.lightspeed.irvnca.sbcglobal.net) has joined #beagle
  • [18:22:58] * KosiNuss_ (~tom@p4FD1016A.dip0.t-ipconnect.de) Quit (Remote host closed the connection)
  • [18:26:29] <aszpain> How do u "say" to the HOST chip on the BB to use the OTG USB port instead of the ECHI one?
  • [18:30:02] <koen> topfs2: I keep getting 19:24:38 T:1100010352 M:336195584 INFO: msg: PICTURE::LoadImage: Unable to open image: Error: (2)
  • [18:30:12] <koen> topfs2: what does xbmc use to load pngs?
  • [18:30:20] <topfs2> cximage, it sucks
  • [18:30:40] <topfs2> I patched for imagemagick which is a tad bloated but better but didn't work on windows :(
  • [18:31:02] <topfs2> still, its weird you get load errors when it works here?
  • [18:31:21] <mru> imagemagick is very, very ugly
  • [18:31:33] <bkero> Ahem, /usr/bin/convert is fucking awesome
  • [18:31:45] <mru> it can do some nice stuff, yes
  • [18:31:53] <topfs2> api wise its rather nicelooking imo
  • [18:31:56] <mru> but the options to convert are far beyond obscure
  • [18:32:05] <topfs2> under the hood it seems rather bad though
  • [18:32:10] <bkero> They're pretty well documented in the info/man page.
  • [18:32:17] <mru> sort of
  • [18:32:39] <mru> I always spend at least half an hour figuring out the proper order whenever I need to mess with an alpha channel
  • [18:32:54] <mru> and it writes 16-bit png files by default even if the input was 8-bit
  • [18:32:58] <mru> that's annoying
  • [18:33:53] <topfs2> well magick++ in Cpp is easy to use for loading and the more simpler operations
  • [18:34:00] <topfs2> And it loads about any format
  • [18:34:04] <mru> c++ is never easy
  • [18:34:19] <mru> I've used the perl api a bit
  • [18:34:34] <mru> as I said, the functionality is good, the interface is poor
  • [18:34:39] <mru> and it's dreadfully slow
  • [18:35:09] <topfs2> the way the achieve the functionality is the thing I hate most
  • [18:35:12] <koen> topfs2: I wonder why I get some pics, but not all
  • [18:35:18] <topfs2> lots of the stuff is scripted
  • [18:35:29] * DanaG (~dana@66-169-236-186.static.snlo.ca.charter.com) has joined #beagle
  • [18:35:32] <mru> "the way to achieve"... aka the interface
  • [18:35:53] * arunjoseph (~arun@192.163.20.231) Quit (Remote host closed the connection)
  • [18:35:57] <topfs2> koen, yeah its darn weird. You could try going into system -> Addons and try to enable another skin and see if it behaves better
  • [18:36:09] <koen> are there more skins installed by default?
  • [18:36:17] <koen> if not, how do I install them?
  • [18:36:18] <topfs2> mru, oh I missunderstood. Thought you meant interface == API. (thinking java)
  • [18:36:22] <koen> and were can I get them?
  • [18:36:29] <koen> the xbmc.org skin section is awfull
  • [18:36:41] * arunjoseph (~arun@192.163.20.231) has joined #beagle
  • [18:36:58] <koen> there's one skin loudly proclaiming it needs teh OMG VERY LATEST, but was last updated in 2009
  • [18:37:11] <topfs2> Go into System -> Addons -> and navigate to skins or go into System -> Apperance and press the skin button and choose "get more" but the latter might not work proper now :)
  • [18:37:21] <mru> topfs2: the only programmatic interface I've used was the perl one
  • [18:37:27] <mru> I imagine the other ones are no better
  • [18:37:37] <mru> but yes, that was easier than command line
  • [18:37:40] <topfs2> Hehe, the skin section will probably get removed or toned down when addons are more prominent
  • [18:39:08] <topfs2> koen did you find it?
  • [18:39:40] <topfs2> but you compile with the exact same commands as me? sounds weird if you get errors then
  • [18:42:07] <koen> topfs2: yeah
  • [18:42:11] <koen> downloading one now
  • [18:46:27] * dl9pf (~quassel@opensuse/member/dl9pf) has joined #beagle
  • [18:46:31] * neo01124 (~neo@122.163.113.214) Quit (Remote host closed the connection)
  • [18:47:25] * dl9pf_ (~quassel@p5B2147FB.dip.t-dialin.net) Quit (Ping timeout: 264 seconds)
  • [18:56:25] * DJWillis (djwillis@cpc1-bath2-0-0-cust327.aztw.cable.virginmedia.com) Quit (Read error: Connection reset by peer)
  • [19:02:50] <ckrinke> Morning
  • [19:03:43] <ckrinke> I'm struggling with a notion with BeagleBoard. That notion is "I need to be able to configure a wireless interface from a serial connection or an ssh/ethernet connection"
  • [19:04:15] <ckrinke> I can run the "Connection Manager" applet in the Angstrom distribution and it configures the 802.11 just fine.
  • [19:04:59] <ckrinke> I have been unable to use iwconfig & ifconfig to get to the same point, so now I am exploring how to run the desktop on the BeagleBoard from my laptop running Linux.
  • [19:05:11] <mru> use wpa_supplicant
  • [19:05:30] <ckrinke> I can do "ssh -X root@beagleboard" and then run an individual X application on the BB, such as xterm
  • [19:05:48] <mru> using wired ethernet I presume...
  • [19:05:49] * rootbit (~root@85-250-120-66.bb.netvision.net.il) has joined #beagle
  • [19:05:50] <ckrinke> But, now a question becomes "How can I run the gnome desktop remotely?"
  • [19:05:53] <rootbit> Hi
  • [19:05:56] <ckrinke> mornitn
  • [19:05:59] <ckrinke> er, morning
  • [19:06:01] <rootbit> Anymore here run Android on a beagleboard?
  • [19:06:05] <ckrinke> I am
  • [19:06:11] <ckrinke> er, sorry, Angstrom
  • [19:06:17] <ckrinke> too many 'A' 's
  • [19:06:42] <rootbit> ha? ckrinke, did you run android on a BeagleBoard?
  • [19:06:52] <mru> android can be run on beagle
  • [19:07:01] <ckrinke> thanks mru, I'll look into wpa_supplicant. On that front, I suspect my understanding is incomplete
  • [19:07:02] <mru> some people engage in such activities
  • [19:07:29] <mru> I don't know how angtrom manages network interfaces in general
  • [19:07:41] <mru> koen should know more
  • [19:08:14] <rootbit> mru, I know its possible
  • [19:08:21] <rootbit> just wanted to check if someone here did it
  • [19:08:24] <ckrinke> Seems to be running Connection Manager which actually works fine from the gnome desktop. Its just that I cannot click on an applet icon in the lower tray across an ssh connection (yet)
  • [19:08:32] <rootbit> I want to build a unibersal remote BeagleBoard
  • [19:08:39] <mru> rootbit: some people who frequent this channel have done such things, yes
  • [19:08:45] <mru> I don't know if any of them are here right now
  • [19:08:55] <rootbit> wanted to speak with someone who might have done something similar
  • [19:09:01] <rootbit> I think it can rock
  • [19:09:06] <rootbit> a touch screen remote
  • [19:09:20] <rootbit> just hack an IR port, onto a beagleboard running android
  • [19:09:25] <rootbit> and then I could write a cool UI
  • [19:09:30] <ckrinke> Has anyone gotten "vncserver" running on a BeagleBoard?
  • [19:09:39] <mru> ckrinke: I would think so
  • [19:09:49] <mru> it's just a computer, nothing fancy
  • [19:10:12] <ckrinke> I see there is a 'vncclient' for the iPad. Dont yet know if I want to experiment down that path or not
  • [19:10:34] <ckrinke> and connect from an iPad to my BeagleBoard embedded device remotely. Might be fun some day.
  • [19:10:57] <ckrinke> For now, I'll settle for connecting from my laptop and running X across the wired ethernet connection
  • [19:13:01] <mru> there are plenty of vnc servers for linux
  • [19:13:07] <mru> any one of them should work on the beagle
  • [19:13:14] <mru> or just tunnel X over ssh
  • [19:13:21] <koen> mru: there is no 'in general' for network stuff in angstrom :)
  • [19:13:32] <koen> it depends if you install networkmanager, connman or nothing
  • [19:13:35] <mru> koen: no common framework for network devices?
  • [19:13:52] <mru> like gentoo uses /etc/init.d/net.$dev start/stop
  • [19:14:01] <koen> at boot it uses /etc/network/interfaces
  • [19:14:10] <koen> and ifup/ifdown reads that
  • [19:14:20] <koen> but the manager you installed is free to override that
  • [19:14:46] * mru never felt the need for another "manager"
  • [19:14:48] <mru> what do they do?
  • [19:15:56] <ckrinke> Well, in my case it may be my naivety, but I have managed to get the wireless working with Connection Manager on the Angstrom demo distribution, but not from a bash command line with iwconfig/ifconfig
  • [19:16:19] <ckrinke> as mru says, it may be my non-understanding of wpa_supplicant
  • [19:16:41] <mru> are you using wpa?
  • [19:16:58] <mru> iwconfig only works with wep
  • [19:17:02] <ckrinke> well, I believe its in the Angstrom demo image, but I havent used it
  • [19:17:06] <mru> which you'd be a fool to use
  • [19:17:07] <ckrinke> ah
  • [19:17:20] <ckrinke> so if the access point is wpa, iwconfig wont work?
  • [19:18:43] * florian (~fuchs@Maemo/community/contributor/florian) has joined #beagle
  • [19:19:54] <mru> iwconfig doesn't handle the wpa key negotiation
  • [19:20:02] <mru> that's what wpa_supplicant is for
  • [19:21:06] <ckrinke> ok, that computes. When I run iwconfig *after* running the Connection Manager applet, I see the key is a 256bit number, like 1234-5678-..... and not the 10 digit key I entered in connection manager in the first place
  • [19:21:47] * Sept (~bakljg@c-24-131-138-21.hsd1.mn.comcast.net) Quit (Ping timeout: 276 seconds)
  • [19:21:50] <ckrinke> So, assuming the only piece missing is the key (and I think that is the only piece), then wpa_supplicant should be able to get me there?
  • [19:23:17] <koen> topfs2: the 'old' themes don't have the sysinfo menu entries
  • [19:23:41] <topfs2> Well does it show more textures atleast?
  • [19:23:53] <koen> the pm3 does
  • [19:24:00] <koen> the other is missing stuff as well
  • [19:27:09] * Ceriand|desktop (~Ceriand@unaffiliated/ceriand) has joined #beagle
  • [19:35:19] <koen> topfs2: crappycam movie will be up in a few mins, crappy movie in 1080p will be up in a few hours
  • [19:35:32] <topfs2> awesome!
  • [19:36:17] <koen> sadly the 1080p one has teh "I filmed a tv" flicker
  • [19:42:01] * Artanis (Artanis@159.108.165.83.dynamic.mundo-r.com) Quit (Ping timeout: 264 seconds)
  • [19:42:01] <ckrinke> off to go study a bit more. Thanks for the advice mru and koen
  • [19:42:29] <koen> topfs2: http://www.youtube.com/watch?v=-CHkOyZ7m2w
  • [19:43:09] <topfs2> oh cool it runs video and gui smooth!
  • [19:43:16] <topfs2> frack I want a xM :)
  • [19:43:39] <koen> till you notice that video and audio are out of sync
  • [19:43:39] <topfs2> btw, LOVE the cars in front of the computer :)
  • [19:44:01] <koen> actually, that's the tv :)
  • [19:44:18] <topfs2> oh! :)
  • [19:44:27] <koen> the xm + tincantools trainer + 3MP camera is also visible
  • [19:44:32] <topfs2> still, awesome
  • [19:46:20] <topfs2> are the audio and video that much out of sync?
  • [19:46:21] * Artanis (Artanis@159.108.165.83.dynamic.mundo-r.com) has joined #beagle
  • [19:46:22] <topfs2> hard to see from the video
  • [19:47:28] <koen> in 199 minutes (according to youtube) you can see for yourself :)
  • [19:47:42] <koen> I'll be doing zzzzzzs by then, though
  • [19:47:55] <topfs2> hehe, cool. The same url?
  • [19:48:06] <koen> no, different one, but same account
  • [19:48:30] <koen> I did use the lens that has horrible barrel distortion, but such is life
  • [19:50:30] <koen> topfs2: btw, omap4 runs the sgx at 300Mhz (C4 -> 110, xM -> 200), so that would be even faster
  • [19:51:01] <topfs2> amazing, that one will hopefully break 1080p then!
  • [19:51:43] <topfs2> I need to reboot now though, I'll push a notice on xbmc.org I think asap. I bet many are interested over at xbmc aswell
  • [19:52:21] <koen> omap4 can do 1080p in "hardware"
  • [19:52:23] * topfs2 (~topfs2@xbmc/staff/topfs2) Quit (Remote host closed the connection)
  • [19:53:45] * matthsu (~matt@61-30-10-70.static.tfn.net.tw) Quit (Ping timeout: 240 seconds)
  • [19:54:29] * Meizirkki (~Meizirkki@ZYYMDCXXVII.gprs.sl-laajakaista.fi) has joined #beagle
  • [20:04:07] * eFfeM (~frans@j200125.upc-j.chello.nl) Quit (Quit: Leaving.)
  • [20:08:29] * Redb3ard (~SF0010MAC@75.110.202.83) has joined #beagle
  • [20:16:06] * JoeSchmo (~jciccone@pool-74-102-95-111.nwrknj.fios.verizon.net) Quit (Quit: Leaving)
  • [20:24:58] <CruNcher> koen what is that for a 1080p stream playing there AVC or ASP ?
  • [20:25:27] <CruNcher> what profile and bitrate ?
  • [20:26:34] * _courvil1e_ (~marc@courville.org) has joined #beagle
  • [20:27:15] * _courvil1e_ (~marc@courville.org) Quit (Client Quit)
  • [20:28:01] <mru> CruNcher: avc
  • [20:29:34] <CruNcher> baseline ? and its running only on the ARM ?
  • [20:31:45] <mru> high profile, runningon a dedicated video unit
  • [20:32:05] <CruNcher> so on the DSP :) anyways nice
  • [20:32:12] <mru> no, not the dsp
  • [20:32:16] <mru> a separate unit entirely
  • [20:32:20] <CruNcher> ahh
  • [20:32:32] <mru> I don't know what the marketing name of it is
  • [20:32:58] <CruNcher> broadcom ?
  • [20:33:04] <mru> are you mad?
  • [20:33:08] <CruNcher> :P
  • [20:33:31] <mru> that said, broadcom's video decoders are rather decent
  • [20:33:37] <mru> shame they can't write proper drivers
  • [20:36:34] <janneg> at least a part of the driver is in the kernel. I haven't looked at it. the userspace part is rather ugly
  • [20:36:36] <CruNcher> that isn't the normal beagleboard though right ?
  • [20:36:54] <mru> janneg: I'm not talking about crystalhd but in general
  • [20:37:10] <mru> CruNcher: omap4 will be on the panda board
  • [20:37:47] <CruNcher> ahh so TI continues with the beagleborad idea nice :)
  • [20:38:05] <CruNcher> especialy for those who thought to by a Tegra2 device and take it apart ;)
  • [20:38:17] <mru> tegra2 is a sorry joke
  • [20:38:45] * Redb3ard (~SF0010MAC@75.110.202.83) Quit (Quit: Redb3ard)
  • [20:39:30] <CruNcher> though the 3D side is entirely different isn't it i mean it's not the SGX stuff but Nvidias i think that's interesting also Cuda can run on it and OpenCL ?
  • [20:39:56] <mru> tegra has some undisclosed nvidia 3d unit yes
  • [20:40:08] <mru> nothing fun there
  • [20:40:16] <CruNcher> and if they implement their very nice Video Decoder Asic they use in their GPUs it will be really good for Multimedia :)
  • [20:40:22] <mru> useful perhaps, but not fun
  • [20:40:33] <mru> tegra2 can't do h264 high profile
  • [20:40:38] <mru> at all
  • [20:40:49] <mru> and it has no neon so software decoding is impossible too
  • [20:40:55] <mru> and forget about vp8
  • [20:41:02] <CruNcher> hmm
  • [20:41:07] <mru> as I said, a sorry joke
  • [20:41:11] <CruNcher> ehh i somehow doubt that
  • [20:41:18] <mru> trust me on this one
  • [20:41:26] <CruNcher> the boxxe box would be a big fail if that is correct
  • [20:41:34] <mru> then it will be a big fail
  • [20:41:55] <CruNcher> and D-Link can to survive another fail they had that with the DSM-330 allready
  • [20:42:31] <mru> dlink is fail by definition
  • [20:42:31] <CruNcher> the great GejBox:-)
  • [20:42:36] * Redb3ard (~SF0010MAC@75.110.202.83) has joined #beagle
  • [20:42:37] <CruNcher> aka DivX Connected :P
  • [20:43:02] * jrmuizel (~jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) Quit (Quit: jrmuizel)
  • [20:43:05] * Redb3ard (~SF0010MAC@75.110.202.83) Quit (Client Quit)
  • [20:45:03] <CruNcher> it would make no sense if Nvidia leaves out the VPx on the tegra2
  • [20:45:15] <mru> who said they had to make sense?
  • [20:45:24] <mru> they only care about making money
  • [20:47:59] * Meizirkki (~Meizirkki@ZYYMDCXXVII.gprs.sl-laajakaista.fi) Quit (Remote host closed the connection)
  • [20:48:25] <CruNcher> mru ehh if you see it that way SGX stuff is also no fun either
  • [20:49:28] <CruNcher> i mean Drivers are in the same propiartary state as Nvidias
  • [20:52:13] <_av500_> wrt gejbox, anybody want one?
  • [20:55:46] <CruNcher> i think it's the only Box in history where the remote button lost its functionality ;)
  • [20:56:28] <CruNcher> "Stage6 Button"
  • [20:57:40] <_av500_> hmm, i forgot all about it
  • [20:59:29] <CruNcher> wonder when Samsung is gonna announce their Cortex A9 stuff could get interesting :)
  • [21:08:49] * jrmuizel (~jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) has joined #beagle
  • [21:09:47] * jrmuizel (~jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) Quit (Client Quit)
  • [21:11:19] * parapete (~pete@host81-151-196-109.range81-151.btcentralplus.com) has joined #beagle
  • [21:13:19] <armin76> mru: did you got around to try the latest kernel on the tegra?
  • [21:14:10] <armin76> what happened to the gejbox?
  • [21:14:31] * jrmuizel (~jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) has joined #beagle
  • [21:21:01] * espindola (~espindola@CPE001a704e2b6d-CM001225dd5348.cpe.net.cable.rogers.com) has joined #beagle
  • [21:24:34] <_av500_> nobody loved it
  • [21:31:46] <mru> CruNcher: I never said sgx was any fun
  • [21:44:10] * mpoirier (~quassel@S0106002369de4dac.cg.shawcable.net) Quit (Ping timeout: 264 seconds)
  • [21:55:09] * jrmuizel (~jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) Quit (Quit: jrmuizel)
  • [21:56:09] * jrmuizel (~jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) has joined #beagle
  • [21:57:02] * jrmuizel (~jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) Quit (Client Quit)
  • [22:00:38] * aszpain (~fuldrul@244.67.18.95.dynamic.jazztel.es) Quit ()
  • [22:01:34] <CruNcher> armin76 the gejbox is still active it was designed as a media streamer server/client and is limited as such other companies from asia rather fast overun it presenting mediastreamers that didn't need the pc for playback unicorn being the most successfull doing so (Realtek solution,efficient and cheap) :)
  • [22:03:29] <CruNcher> though it had some nice ideas from DivX Labs they entirely build the software side :)
  • [22:04:19] <CruNcher> and it was the only player supporting Stage6 Obviously back then
  • [22:05:13] <CruNcher> now DivX is concentrating more on DivX TV :) or should we say Sonic/DivX is :P
  • [22:08:27] <CruNcher> btw the Software side is freely available :)
  • [22:09:32] <CruNcher> so you can see DivX own Media Center Research on the PC too :)
  • [22:10:34] * DanaG (~dana@66-169-236-186.static.snlo.ca.charter.com) Quit (Disconnected by services)
  • [22:11:46] * DanaG1 (~dana@66-169-236-186.static.snlo.ca.charter.com) has joined #beagle
  • [22:12:11] * DanaG1 (~dana@66-169-236-186.static.snlo.ca.charter.com) Quit (Remote host closed the connection)
  • [22:13:03] * florian (~fuchs@Maemo/community/contributor/florian) Quit (Quit: Verlassend)
  • [22:14:04] * jrmuizel (~jrmuizel@CPE001f5be79d0f-CM0017ee62f8b0.cpe.net.cable.rogers.com) has joined #beagle
  • [22:15:19] <CruNcher> though its windows only
  • [22:15:28] <CruNcher> http://www.youtube.com/watch?v=qVJI5GnyVzU
  • [22:24:46] <CruNcher> http://www.youtube.com/watch?v=FfI4J3IDATE
  • [22:27:09] * calculus (~calculus@gentoo/user/calculus) Quit (Ping timeout: 260 seconds)
  • [22:35:03] <CruNcher> the 1-9 seek is a great idea :) 1=10% seek 2=20% seek that was a awesome idea :)
  • [22:36:54] * ckrinke (~IceChat7@76-218-61-186.lightspeed.irvnca.sbcglobal.net) Quit (Quit: Easy as 3.14159265358979323846...)
  • [22:37:14] <CruNcher> also using the same methology for zooming a picture on the remote
  • [22:39:09] * calculus (~calculus@gentoo/user/calculus) has joined #beagle
  • [22:39:10] * t_s_o (~tso@183.84-49-135.nextgentel.com) Quit (Remote host closed the connection)
  • [22:42:01] * parapete (~pete@host81-151-196-109.range81-151.btcentralplus.com) Quit (Quit: /kick evilpaul)
  • [22:44:06] <CruNcher> http://www.youtube.com/watch?v=g-MlWlB5q7o
  • [22:52:43] * denix|otg (~denys@pool-71-251-53-25.washdc.east.verizon.net) has joined #beagle
  • [22:56:51] <CruNcher> http://www.youtube.com/watch?v=U4J084y0hXA - the xtreamer has 1 problem though ;) the realtek chip gets a little hot ;)
  • [22:57:30] <mru> realtek ... problem, some things never change...
  • [23:01:24] <CruNcher> yeah Omap4 solutions gonna blast this away :D
  • [23:02:50] <CruNcher> though Omap4 solutions most probably will be to expensive for these things ;)
  • [23:03:00] <denix|otg> you mean "blaze" this away? :)
  • [23:04:11] <denix|otg> yup, blaze tablet is $2K+...
  • [23:05:47] <CruNcher> 200$ for the Boxxee box most will not pay with such 99$ solutions on the market that can do almost the same :P
  • [23:06:44] <CruNcher> but ok thats what Nvidia will realize soon enough ;)
  • [23:07:15] <theholyduck> CruNcher, are you saying people won't spend twice the money for a a badge of suckerness?
  • [23:07:33] * theholyduck points CruNcher at the entire apple product line
  • [23:08:04] <theholyduck> why wouldnt freetards (as i like to call them) waste money on something thats "truly open source" and all those other things
  • [23:10:00] <theholyduck> CruNcher, the only thing i can see, is if the boxee stuff implements full libass with propper mkv demuxing and fonts.
  • [23:10:15] <theholyduck> that way they could score some buys from the anime crowd
  • [23:10:46] <CruNcher> http://forum.xtreamer.net/viewtopic.php?f=28&t=2958
  • [23:10:56] <CruNcher> those asians aren't sleeping ;)
  • [23:11:25] <theholyduck> i THINK libass is fast enough to work on embedded devices
  • [23:11:35] <theholyduck> atleast, its much faster than all the other ass renderers around
  • [23:11:38] <theholyduck> and pretty complete
  • [23:13:14] * matthsu (~matt@61-30-10-70.static.tfn.net.tw) has joined #beagle
  • [23:20:51] * Redb3ard (~SF0010MAC@75.110.202.83) has joined #beagle
  • [23:25:40] * raster (raster@enlightenment/developer/raster) has joined #beagle
  • [23:27:37] * Ira__ (44519dad@gateway/web/freenode/ip.68.81.157.173) has joined #beagle
  • [23:28:23] <Ira__> Hi Anyone Got A "Special" Development Environment or Library for Python With BeagleBoard?
  • [23:35:54] * emeb (~ericb@ip72-223-81-194.ph.ph.cox.net) has joined #beagle
  • [23:39:55] * rsalveti (~rsalveti@187.115.155.46) has joined #beagle
  • [23:42:31] <CruNcher> http://shop.xtreamer.net/Support/questions/78/What+is+the+Difference+between+Xtreamer+and+other+mediaplayers+%3F
  • [23:42:59] <CruNcher> the craziest thing in that whole text even if that direct attack of the competition is allready crazy in some countries ;)
  • [23:43:04] <CruNcher> is that one :P
  • [23:44:07] <CruNcher> "The Xtreamer has the advantage of the busy forum and community behind it. It was made by people who like movies and porn very much the same as most media players are. With this goal and target price the unit was designed and is manufactured."
  • [23:44:56] <CruNcher> crazy asians
  • [23:45:18] <mru> porn...
  • [23:45:27] <mru> rare to see that mentioned in marketing material
  • [23:45:58] <mru> sure you didn't get the brochure for the XXXtreamer by mistake?
  • [23:46:06] <CruNcher> hehe
  • [23:46:13] <CruNcher> yeah im sure
  • [23:47:05] <CruNcher> so this thing is manufactured with porn in mind :D
  • [23:48:16] <CruNcher> now it should be no surprise why the chip gets a little HOT sometimes ;)
  • [23:49:11] <raster> hot naked chips
  • [23:51:48] <CruNcher> hey raster :)
  • [23:52:32] <raster> no time to greet now. busy ogling hot naked chips :)
  • [23:52:33] <CruNcher> you where gone fast yesterday i wanted to say thanks for the S5PC100 info
  • [23:53:04] <raster> lots of silicon enhancements..... drool
  • [23:53:08] <raster> ok
  • [23:53:10] <raster> enough silliness
  • [23:53:11] <raster> :)
  • [23:53:14] <CruNcher> hehe
  • [23:53:15] <raster> mornin' :)
  • [23:53:22] <raster> CruNcher: np
  • [23:53:23] <raster> note
  • [23:53:26] <raster> c110
  • [23:53:29] <raster> not 100
  • [23:53:30] <CruNcher> yep
  • [23:53:44] <raster> but as such i think there is very little around about the c100 or c110
  • [23:54:05] <raster> check for info on the galaxy-s - thats got lots of c110 goodies in the public
  • [23:54:16] <raster> and otherwise omap34xx and 35xx has a lot out there
  • [23:54:25] <CruNcher> there are those rumors that most of the A4 is based on Samsungs Design :P
  • [23:54:32] <raster> omap 36xx and omap4 i think are pretty rare
  • [23:54:36] <raster> if out at all
  • [23:54:46] <raster> dunno
  • [23:54:50] <raster> i dont work for lsi
  • [23:55:03] <mru> omap4 is not out yet
  • [23:55:17] <mru> 36xx should be available in volume
  • [23:55:21] <raster> (samsung lsi == the guys who do the chips and stuff. samsugn is a massive place and different divisons effectively work as different companies)
  • [23:55:35] <CruNcher> yeah raster looked at the galaxy-s (android) and wave (bada) :)
  • [23:55:50] <raster> mru: indeed - but as such omap4, tegra2 and s5pc210 are what i am keeping my eye on
  • [23:56:00] <CruNcher> though not much to find about Video Playback capabilities as allways :P
  • [23:56:04] <raster> silly nvidia didnt include any neon units tho
  • [23:56:05] <raster> poopie
  • [23:56:14] <CruNcher> and the Demos they show don't tell much
  • [23:56:23] <raster> omap4 - on paper - looks good
  • [23:56:30] <CruNcher> except that Super Amoled is the thing :P
  • [23:57:14] <mru> tegra is a huge disappointment as far as I'm concerned
  • [23:57:15] <raster> CruNcher: one thing i can say. super amoled... you just dont get how nice it is until you see it in real life in front of you
  • [23:57:18] <CruNcher> ah raster S5PC210 is the Cortex A9 version ?
  • [23:57:22] <raster> i mean... black is BLACK
  • [23:57:32] <raster> screen turns on and u dont even know its on
  • [23:57:42] <CruNcher> yeah they mention that ;)
  • [23:57:47] <CruNcher> and 0 power consumption
  • [23:57:48] <raster> unlike all lcd's that have anywhere from a bright to a dim grey - u KNOW its on
  • [23:57:57] <raster> the colors are .... vibrant
  • [23:58:00] <raster> they pop... so to speak
  • [23:58:04] <raster> there is a downside tho
  • [23:58:20] <mru> always is...
  • [23:58:29] <raster> colorspace res suffers
  • [23:58:43] <raster> with lcds at that size/res/dpi u have 3 elements per pixel
  • [23:58:53] <raster> with oled.. u have 2.5
  • [23:59:40] <mru> http://hardwarebug.org/wp-content/uploads/2010/03/img_3147.jpg
  • [23:59:45] <CruNcher> raster im not sure if Nvidia needs neon
  • [23:59:52] <mru> ^^ nexus one screen closeup photo
  • [23:59:57] <raster> ie blue is shared between 2 horizontal pixels