| 00:00.03 | truki | ah :/ |
| 00:00.47 | techn_ | truki: problem could be my microUSB -> femaleUSB converter which I bought |
| 00:00.53 | truki | but these hwpacks from sunxi.org works charmly |
| 00:01.37 | truki | have you tried binaried? |
| 00:01.46 | truki | s/binaried/binaries |
| 00:02.20 | techn_ | which binaries? :) |
| 00:06.52 | rz2k | s/rz2k/ssvb/ |
| 00:09.55 | truki | i mean of those hwpacks called a13_mid and a13_olinuxino, you then mix and match other hf rootfs |
| 00:10.38 | *** join/#arm-netbook lerc (~quassel@121-74-240-231.telstraclear.net) |
| 00:11.20 | techn_ | truki: I'm using that same script which generates those while I'm developing |
| 00:11.26 | rz2k | good night. |
| 00:11.32 | truki | btw stage or 3.4 is more stable? |
| 00:11.36 | techn_ | rz2k: gn |
| 00:12.01 | truki | techn_: and still not enumerating the devices? |
| 00:12.38 | techn_ | stage has changes that are going to that branches "master".. stage aka testing |
| 00:13.16 | truki | yeah but 3.4 doesnt seem to be tested too much either |
| 00:13.41 | techn_ | 3.4 has some stuff missing that is in 3.0 |
| 00:14.13 | truki | am i retard or my motto is wrong? the newer the buggier and the older the stabler? :P |
| 00:14.53 | truki | well those stuff are always irrelevant fır a simple tablet user... |
| 00:15.15 | truki | even 2.6 would suit my needs for now |
| 00:15.30 | penguin42 | truki: It depends how the stuff was ported to a platform |
| 00:15.40 | techn_ | https://github.com/linux-sunxi/linux-sunxi/issues/48 |
| 00:15.46 | truki | s/fir/for |
| 00:15.59 | penguin42 | truki: If the guys who did the chip you're interested in did it on version X and haven't bothered to keep it updated then it slowly rots unless someone maintains it |
| 00:16.28 | penguin42 | truki: It also happens with new chips that they might just try and get one version nice and everything working before keeping it up to date |
| 00:17.48 | truki | yeah there must be an optimal point that for a casual user it'd be enough... but for developers, it's a never ending story... |
| 00:18.24 | penguin42 | truki: Well if they get the chip support into the upstream Linux kernel stuff gets a lot more stable than it all being maintained separately |
| 00:19.03 | truki | still they are sending contributions, right? |
| 00:19.38 | truki | any timeline for mainlining ends? |
| 00:21.49 | penguin42 | I don't think I've seen any of there stuff go upstream |
| 00:21.56 | truki | techn_: lol allwinnerization of 8192cu... this one is already ubiqutious and working even in 3.0 |
| 00:22.56 | techn_ | truki: Yes. but not in 3.4 |
| 00:23.32 | techn_ | after those are done we could move our master to 3.4 :/ |
| 00:23.39 | truki | penguin42: http://linux-sunxi.org/Mainlining_Effort |
| 00:24.22 | truki | techn_: hopefully :/ |
| 00:25.00 | techn_ | but let see how mainlining goes.. there is quite a lot stuff tbd |
| 00:25.19 | truki | yup they are just for a start it seems |
| 00:25.35 | techn_ | hopefully it will accelerate when everyone gets their cubie :) |
| 00:26.28 | jelly-home | wonders whether allwinner ever implemented hdmi cec on A10 |
| 00:26.30 | truki | u mean of those cubieboards? |
| 00:26.36 | techn_ | there seems to be 1,5k subscribers for cubieboard ML.. only 150 for linux-sunxi ML :( |
| 00:26.53 | truki | lol |
| 00:27.26 | jelly-home | and if you get 7.5 people out of that sending a patch, consider yourself lucky |
| 00:28.48 | techn_ | jelly-home: that's true :( |
| 00:29.05 | jelly-home | hopes to be the .5 |
| 00:29.57 | techn_ | as I suspected.. most of the ppl are thinging it's as well supported as rasberry pi |
| 00:30.36 | techn_ | or atleast some ppl |
| 00:37.47 | penguin42 | techn_: Once stuff comes together it should be ok, but it's unlikely to ever get quite that following (or if it does Tom is going to be damn busy!) |
| 00:44.43 | libv | techn_: as long as those followers are a bit more sane... |
| 00:46.08 | jelly-home | I kinda hope the eoma format magically becomes a success |
| 00:56.39 | *** join/#arm-netbook merbzt (~benjamin@c-83-233-243-128.cust.bredband2.com) |
| 01:01.01 | *** join/#arm-netbook hp__ (~kvirc@118-168-205-7.dynamic.hinet.net) |
| 01:16.31 | *** join/#arm-netbook stefanro1 (~stefan@p57B94385.dip.t-dialin.net) |
| 01:50.59 | *** join/#arm-netbook e-ndy (~e-ndy@194.213.226.242) |
| 01:52.21 | *** join/#arm-netbook hno (~hno@squid/developer/hno) |
| 02:05.00 | *** join/#arm-netbook Skaag_ (~lunix@cpe-72-225-221-14.nyc.res.rr.com) |
| 02:08.24 | Dessimat0r | ssvb: is 'cp: cannot state 'build/boot.scr': No such file or directory' any concern? |
| 02:08.30 | Dessimat0r | *stat |
| 02:09.17 | techn_ | no worry |
| 02:09.28 | Dessimat0r | ah |
| 02:09.56 | techn_ | it's optional.. you can adjust u-boot parameters with it |
| 02:10.31 | Dessimat0r | and if I add CONFIG_SUNXI_IGNORE_ATAG_MEM=y to make after compiling, will it modify the built objects as if I had used that option on a clean build? |
| 02:10.41 | Dessimat0r | or should I clean and recompile from scratch? |
| 02:11.10 | techn_ | if you add that to .config in build directory |
| 02:11.37 | Dessimat0r | oh, i just did it on the command line after 'make' |
| 02:11.49 | techn_ | ah |
| 02:11.56 | Dessimat0r | along with CONFIG_USB_GADGET=N |
| 02:12.13 | techn_ | dunno if it works that way.. but nice to know if it works :) |
| 02:12.38 | techn_ | in theory it can work |
| 02:21.56 | Dessimat0r | out of interest, what do I do with the hwpack? |
| 02:22.05 | Dessimat0r | i think I used some intermediate files before |
| 02:22.13 | Dessimat0r | when constructing the image |
| 02:23.08 | Dessimat0r | i guess I need to get a rootfs if I want to go that direction |
| 02:23.14 | techn_ | you can use that for sunxi-media-create.sh |
| 02:23.36 | Dessimat0r | ah |
| 02:23.43 | techn_ | and create sd card with your stuff |
| 02:23.52 | Dessimat0r | where do I get an Android 4.0.4 rootfs from? |
| 02:24.14 | techn_ | but if you are modifying nand.. you'll need to unzip that pack |
| 02:24.21 | techn_ | and take what you need |
| 02:24.27 | Dessimat0r | ah, ok :D |
| 02:24.39 | techn_ | also there is no android support currently |
| 02:24.52 | techn_ | otherwise than building |
| 02:25.15 | Dessimat0r | no support for 3.4 as well as 3.0? |
| 02:25.39 | techn_ | I ment android hwpack support |
| 02:25.41 | Dessimat0r | or 3.0 works? |
| 02:25.43 | Dessimat0r | ah |
| 02:26.41 | Dessimat0r | so I have to take the rootfs from an existing build, and merge it into the image to be flash |
| 02:26.46 | Dessimat0r | but the building itself cannot support |
| 03:04.15 | *** join/#arm-netbook naobsd (d28ad09e@gateway/web/freenode/ip.210.138.208.158) |
| 03:07.55 | naobsd | did anyone try A10/A13 source on http://service.i-onik.de/ ? |
| 03:09.20 | naobsd | I know https://github.com/allwinnerwk/ and https://github.com/linux-sunxi but |
| 03:10.18 | naobsd | I never saw ics v1.5 complete source (I'm in the middle of downloading so I'm not sure it's "complete" yet) |
| 03:58.30 | Dessimat0r | techn_: flashed it, but still not working |
| 03:58.32 | Dessimat0r | damn |
| 03:58.57 | Dessimat0r | it does nothing on boot still |
| 04:03.51 | *** join/#arm-netbook aholler_ (~aholler@p57B205D6.dip0.t-ipconnect.de) |
| 04:36.45 | *** join/#arm-netbook Quarx (~Quarx@46.233.233.118) |
| 05:35.07 | *** join/#arm-netbook L84Supper (~Larch@unaffiliated/l84supper) |
| 06:17.24 | *** join/#arm-netbook soooga (~soooga@175.155.23.210) |
| 06:18.00 | *** join/#arm-netbook gsilvis (~almostsix@50.12.163.241) |
| 06:20.49 | *** join/#arm-netbook ph0en1x (~ph0en1x@c-98-210-135-53.hsd1.ca.comcast.net) |
| 06:22.02 | ph0en1x | hey all - i'm interested in getting into the mk802 development scene - are there any existing vagrant box files already set up to do development? |
| 06:23.09 | ph0en1x | merry christmas also :P |
| 06:24.17 | *** join/#arm-netbook soooga (~soooga@175.155.23.210) |
| 06:24.18 | rm | I had to look up "vagrant" in a dictionary, and I still don't get what do you mean |
| 06:26.30 | ph0en1x | ah, yeah, i have a mac - i use vagrant to quickly provision oracle virtualbox virtual machines |
| 06:26.57 | ph0en1x | stripped, base virtualbox images are packaged into .box files for easy distribution |
| 06:27.10 | rm | oh, it's a name of a piece of software |
| 06:27.13 | rm | ok, never heard of it |
| 06:28.02 | ph0en1x | yeah, it's pretty useful stuff if you deal with a lot of virtual machines, provisioning remote systems using Chef or Puppet, etc |
| 06:28.36 | ph0en1x | anyhow, it looks (through extensive poking about these last few days) that people are using something called Buildroot? on ubuntu? |
| 06:30.23 | ph0en1x | do you know if the mk802 has usb serial output? |
| 06:31.04 | ph0en1x | i know I can plug usb into my CuBox and use Putty in serial mode to see console output without hdmi |
| 06:32.37 | *** join/#arm-netbook soooga (~soooga@175.155.23.210) |
| 06:33.40 | rm | it does have UART "pads" http://linux-sunxi.org/File:Mk802_uart.jpg |
| 06:34.00 | rm | those are 3.3V, so need to be connected via a TTL convertor |
| 06:34.28 | ph0en1x | ah - looks annoying :P |
| 06:36.44 | ph0en1x | yeah looks like i'd need a usb ttl converter and solder some wires up to those pads |
| 06:38.39 | ph0en1x | bbl |
| 06:55.30 | *** join/#arm-netbook ganbold (~ganbold@202.179.0.162) |
| 07:10.42 | *** join/#arm-netbook rz2k (~rz2k@95-25-166-101.broadband.corbina.ru) |
| 07:16.31 | *** join/#arm-netbook ganbold (~ganbold@202.179.0.162) |
| 07:40.34 | *** join/#arm-netbook ph0en1x (~phenx@205.204.67.236) |
| 07:41.30 | *** join/#arm-netbook hipboi (~hipboi@27.23.148.61) |
| 08:28.21 | *** join/#arm-netbook rellla (~Thunderbi@p4FE563FE.dip0.t-ipconnect.de) |
| 08:52.27 | *** join/#arm-netbook eFfeM (~frans@c73189.upc-c.chello.nl) |
| 09:37.27 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 09:40.55 | *** join/#arm-netbook rsalveti_ (~rsalveti@unaffiliated/rsalveti) |
| 10:13.04 | *** join/#arm-netbook soooga (~soooga@175.155.23.210) |
| 10:22.39 | *** join/#arm-netbook Skoti_ (589cdff4@gateway/web/freenode/ip.88.156.223.244) |
| 10:26.31 | *** join/#arm-netbook rellla (~Thunderbi@p4FE563FE.dip0.t-ipconnect.de) |
| 11:03.35 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
| 12:47.42 | *** join/#arm-netbook ibot (~ibot@rikers.org) |
| 12:47.42 | *** topic/#arm-netbook is EOMA: Embedded Open Modular Architecture - Don't ask to ask. Just ask! - http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68 - ML arm-netbook@lists.phcomp.co.uk - Logs http://ibot.rikers.org/%23arm-netbook or http://irclog.whitequark.org/arm-netbook/ - http://rhombus-tech.net/ |
| 12:53.12 | *** join/#arm-netbook Gumboot (~sh1@rev.bovine.muck.net.nz) |
| 13:23.51 | *** join/#arm-netbook _BJFreeman (~bjfree@234.sub-75-244-146.myvzw.com) |
| 14:10.21 | *** part/#arm-netbook _BJFreeman (~bjfree@234.sub-75-244-146.myvzw.com) |
| 14:12.29 | *** join/#arm-netbook merbzt (~benjamin@c-83-233-243-128.cust.bredband2.com) |
| 14:32.13 | slapin | company I work in made its infrastructure MS-based and moved it to amazon... dangerous times... |
| 14:32.54 | slapin | s/in /with / |
| 14:35.04 | penguin42 | slapin: Why dangerous? |
| 14:40.14 | slapin | penguin42: when it is very important to have remote it infrastructure, and move it aboard on clouds, these times are dangerous |
| 14:41.53 | penguin42 | slapin: I'm not sure; clouds fail of course - but so do stuff people build inside there own companies; the difference is when amazon fail there are millions of people screaming at them to get it fixed so they do pretty quickly |
| 14:45.04 | slapin | penguin42: when you move user's desktops over rdesktop to MS TSE2008 aboard, that is trading stability for security = dangerous times. |
| 14:45.22 | buZz | ah lol |
| 14:45.29 | buZz | your company is stuck in mainframe time |
| 14:46.17 | slapin | that it means it is more important to have control of company data (with afst disconnection/destruction) than user's performance |
| 14:46.35 | slapin | s/afst/fast/ |
| 14:46.45 | penguin42 | slapin: Ah, moving desktops like that yes, I'd agree from your point of view |
| 14:47.26 | buZz | i dont see why there is this need to virtualize desktops |
| 14:47.36 | penguin42 | buZz: Less admin |
| 14:47.39 | slapin | buZz: more control |
| 14:47.47 | buZz | let the user play admin on his own system |
| 14:47.53 | penguin42 | buZz: It becomes trivial to nuke a desktop and reimage it, no one has to get up and do somethign |
| 14:48.04 | buZz | if he's uncapable to do so, fire him and hire someone who can |
| 14:48.06 | penguin42 | and as slapin says, more control |
| 14:48.36 | buZz | hmhm |
| 14:48.50 | RaYmAn | you can't really expect regular users to have that kind of knowledge. |
| 14:48.59 | buZz | yes you can :P |
| 14:48.59 | penguin42 | buZz: depends on the user of course, secretaries bank workers and all that kind of thing then they really shouldn't be doing anything; more of a problem for those of us who know what they're doing |
| 14:49.04 | RaYmAn | You generally don't hire them for their IT skills, but because they are good at something else ;) |
| 14:49.25 | buZz | RaYmAn: there is this line on the jobvacancy 'computer experience' |
| 14:49.26 | buZz | :P |
| 14:49.41 | RaYmAn | from an admin point of view, users with "computer experience" are the worst |
| 14:49.46 | penguin42 | buZz: That means 'can run word' |
| 14:49.50 | RaYmAn | indeed |
| 14:49.51 | RaYmAn | ^^ |
| 14:49.57 | buZz | i wouldnt virtualize a user's stapler, just because he lacks the mechanical knowledge to fix one |
| 14:50.03 | slapin | buZz: imageine: you want more girls in your office to make atmosphere more healthy, and it is far less important that they can't admin their pcs, it is better for them to have good bodies. |
| 14:50.13 | buZz | slapin: lol |
| 14:50.19 | buZz | imho NO |
| 14:50.25 | RaYmAn | the arguments in here are quickly deterioating :P |
| 14:50.30 | buZz | but hey, i stopped working in IT long ago :P |
| 14:50.36 | penguin42 | slapin: Tsk tsk! |
| 14:50.37 | buZz | cause IT is poison |
| 14:50.45 | penguin42 | buZz: Haha yes, I used to run a small IT group |
| 14:50.58 | RaYmAn | the "usual" argument for virtualizing user desktops is to be able to continue using old hardware |
| 14:51.12 | penguin42 | anyway, look up Sutherlands wheel of reincarnation |
| 14:51.33 | penguin42 | it basically describes bouncing between centralised and distributed desktop/user stuff - happens every decade or two |
| 14:54.10 | buZz | :) |
| 14:54.39 | buZz | reminds me of http://www.youtube.com/watch?v=yzLT6_TQmq8 |
| 14:56.00 | slapin | well, remember 90's X terminals everywhere, and then people didn't know what to do with 19" workstation displays and these terminals. Not cost-effective, and quite not efficient enough for users to like them these days... |
| 14:56.20 | buZz | X terminals always were so sexy to me |
| 14:56.25 | buZz | i used to collect them |
| 14:56.26 | slapin | thin clients are still no-no in not-specialized environments |
| 14:57.25 | slapin | buZz: I like the concept in itself too, and deploy it a lot for various control systems, but no requests from ordinary users... |
| 14:57.36 | buZz | yeah exactly |
| 14:57.43 | buZz | ordinary users are boring |
| 14:59.04 | penguin42 | with so much stuff done via webbrowsers anyway these days |
| 15:00.21 | *** join/#arm-netbook tinti (~tinti@201.62.162.119) |
| 15:01.39 | penguin42 | actually an A10 card should do great for a x-terminal,rdesktop,fixed web access thing |
| 15:02.04 | buZz | A10 could also run X clients and be host to apps to display on a x-terminal ;) |
| 15:02.43 | buZz | for me X terminals are 'over' because i never had one that supported GLX etc :P |
| 15:02.48 | penguin42 | buZz: I wouldn't want to put too much on one, but I guess compared to the things that were backing our xterminals 10 years ago then yes |
| 15:03.11 | buZz | hehe penguin42 , i am building my new laptop around a A10 |
| 15:03.16 | slapin | X-terminal-like solutions are good in control systems environments and everywhere, where you need to control a lot of visual data, which is heavily integrated. You display lots of green/red bubbles and operator's mind becomes well trained and reacts fast and can provide solution for problems faster than if he had to shuffle windows, had other things to do on pc, like playing tetris-bsd, or for audio alerts. And is less pressed than with audio ale |
| 15:03.21 | buZz | its fast enough for all i want |
| 15:03.50 | buZz | slapin: /script load splitlong.pl :) |
| 15:04.13 | specing | buZz: it would run for a week on a normal fatass 9-cell laptop battery |
| 15:04.21 | buZz | or to put it in other words, that sentence was too long |
| 15:04.25 | slapin | buZz: tl;dr? |
| 15:04.35 | buZz | slapin: tl;ircservercropped |
| 15:04.55 | buZz | specing: i measured about 5 hours on 3 cell inside a motorola lapdock |
| 15:05.14 | buZz | more than enough for now :) |
| 15:05.35 | buZz | also, thats without any power management, just clocked at 1ghz straight, wifi on all the time, display on, etc etc |
| 15:05.53 | buZz | am i right that A10 can be clocked down to 30Mhz ? |
| 15:05.55 | specing | How is power management these days? |
| 15:06.02 | specing | buZz: 60Mhz |
| 15:06.10 | slapin | buZz: anyway, I have somewhere an old X terminal with glx support and DPS (diplay postscript) support, I used it with OpenStep and some old SGI app |
| 15:06.15 | buZz | hmm, still it lists 30Mhz in the options? |
| 15:06.22 | buZz | see cpufreq-info |
| 15:06.29 | specing | buZz: thats used in sleep AFAIK |
| 15:06.33 | buZz | slapin: wow, nice |
| 15:06.44 | buZz | specing: also those freqs go all the way up to 1.5ghz |
| 15:07.00 | slapin | buZz: but now I can't make my nvidia drivers show anything 3d on it. |
| 15:07.15 | buZz | X terminal with nvidia hardware? :O |
| 15:07.19 | buZz | oh yeah |
| 15:07.22 | slapin | buZz: no |
| 15:07.28 | buZz | nvidia probably replaced your libGL |
| 15:07.35 | buZz | because they hate you |
| 15:07.38 | slapin | my pc with nvidia drivers, yes |
| 15:07.52 | slapin | buZz: I still don't understand why they replace libs |
| 15:08.02 | buZz | because they dont want to be normal |
| 15:08.24 | slapin | nobody wants to be "normal", it is understandable, but why libs? |
| 15:08.45 | buZz | my guess is dirty hacks |
| 15:10.00 | penguin42 | slapin: Because a lot of the stuff is done in the libGL and not all in the X server |
| 15:10.18 | penguin42 | slapin: It's not like X of old, not all the rendering is done on the server |
| 15:10.38 | slapin | damn innvators |
| 15:11.38 | slapin | break avarything around to make santa on window's header jump and fart instead of giving some thought and bring some elegant solution |
| 15:11.59 | slapin | damn shuffling of bitmaps |
| 15:12.00 | buZz | improving the world is never in the interest of a commercial party |
| 15:12.21 | penguin42 | slapin: I think 'wayland' might be part of the elegant solution - don't know if it actually works |
| 15:13.40 | slapin | if it will be plugin for X11, and all work will be over Xlib, and network optimizations for bitmap might be made transparent for X apps, then it is good enough solution |
| 15:13.48 | slapin | likes X11 |
| 15:14.07 | penguin42 | slapin: Yeh, but I think people came to the conclusion that was just too much overhead when you actually wanted fast 3d stuff |
| 15:14.26 | penguin42 | slapin: Just too much squeezing all the stuff down a pipe through a single point of control |
| 15:16.57 | slapin | penguin42: but they might make something better, not replace good, but slow infrastructure with bad absence of infrastructure and any means of any architectual thought/ |
| 15:17.31 | slapin | dhey know it is bad, but they can't make anything better and destroy everything |
| 15:17.40 | slapin | s/dhey/they/ |
| 15:18.26 | slapin | I still can't see any good concept in generic UNIX graphics, anything modern and as brilliant. |
| 15:21.37 | penguin42 | slapin: It's worth looking at how the DRI stuff works in the kernel/X these days - I don't know enough about it to comment in detail, and look at the wayland design |
| 15:21.43 | slapin | avarybody looks at Windows patchwork of API - they made it ad-hok and just to run games, X11 is far more generic than this, and far more well thought and written. Time changed, yes, but there is still no such well thought idea. Only 'draw directly to hardware/gimme direct fast API to draw so I can make 6000fps instead of 2000' thing |
| 15:23.00 | jelly-home | and yet their patchwork works so much better in practice |
| 15:23.03 | penguin42 | slapin: I'm not sure it's quite that bad, GL/GLes is an API to work to with X11, and the app doesn't need to know about the stuff underneath (although the fact it's now split from GL to GLes is depressing - although that's also another thing that changes every decade or two) |
| 15:23.19 | slapin | penguin42: Wayland is just compositor. No network support thought in, no resource infrastructure, no anything. All is left for applications. Just some ad-hoc thing for consoles, little improvement over framebuffer. |
| 15:24.32 | penguin42 | slapin: But X network stuff hasn't been used heavily for decades - everyone uses VNC because X network stuff is just too slow in practice for non-trivial apps, and since display postscript didn't happen there was never any support for putting more complex stuff across the protocol; that's what Display Postscript, Sun's NeWS, etc was supposed to do - but it never worked out |
| 15:24.44 | slapin | penguin42: it might be good if it is used as basis, but it is simply not enough. They decided that while X doesn't provide good enough API for apps with heavy graphics demands, these features are not needed at all. |
| 15:26.51 | slapin | penguin42: DPS is quite good, but current software wants to shuffle bitmaps and do all work itself, not sending server commands, that's because X11 is not good for them, that's because wayland saw started |
| 15:27.39 | penguin42 | slapin: Dunno, current software is also doing plenty via GL, and you can do remote GL, but again that's not too good once you put loads of texturing on |
| 15:28.31 | slapin | penguin42: X network stuff could be reworked, even so, that bitmaps shuffling will work not worse than with VNC, but actually everybody cry we don't need no network transparency!, so no real work was made |
| 15:28.51 | penguin42 | slapin: I think they might be right though! |
| 15:29.40 | penguin42 | slapin: Our network environment is very different these days - with wireless and internet connections we want to be able to get back to our desktops when a connection drops, X was never able to do that - but it's easy with vnc |
| 15:30.47 | penguin42 | (also look at spice that's similar to vnc but more modern and a bit higher level - I think more like rdesktop) |
| 15:30.50 | buZz | 16:23:52 < jelly-home> and yet their patchwork works so much better in practice |
| 15:30.56 | slapin | penguin42: this all require thought. You always have some limits, but if you need network X11 - you can get it. Only some small commertial projects port X11 for their needs improving network tranparenct, writing proper apps. But general public, no. Personal computers are personal. No strings attached. |
| 15:30.56 | buZz | did you see Valve's result? |
| 15:31.22 | buZz | where they ported a windows game to linux, moved to opengl and had such an improvement in FPS that they ported the linux version _back_ to windows |
| 15:31.35 | buZz | made me roflmao |
| 15:32.08 | penguin42 | slapin: I use X at work all the time, and do stuff remotely all over the world - very rarely do long distance X forwarding though |
| 15:33.20 | penguin42 | slapin: I think if anything you should blame HTML and Javascript - what you might have done as a forwarded X application is now easier to do as a javascript thingy running on the client end - because X never got the concept of a widget into it's protocol where you just had to send 'clicked' |
| 15:33.30 | penguin42 | slapin: And all the rendering was done on the client side |
| 15:34.01 | *** join/#arm-netbook rz2k (~rz2k@95-25-166-101.broadband.corbina.ru) |
| 15:35.22 | slapin | penguin42: about 5 years ago I developed dps extension based on ghostscript, based on long-dropped code at sf.net. Now I get another request for that, but based on cairo. So there is a small demand for this. |
| 15:36.28 | slapin | Also I made some optimization for bitmaps (fake server bitmaps made to reduce traffic), everything is doable, if there was enough demand. Nobody cares, though. |
| 15:36.51 | penguin42 | slapin: Nice |
| 15:36.54 | slapin | Disconnection can be fixed on XDM level without too much trouble. |
| 15:37.00 | penguin42 | how? |
| 15:39.38 | slapin | penguin42: my original thought was to block Xlib calls until Xserver appears again, but it was good for my apps (sensors display), probably something better might be made from this. |
| 15:41.07 | slapin | penguin42: better approach is to change Xlib work with remote displays, to implement cache. X11 knows its intrinics better than special Xserver which is vnc. |
| 15:41.34 | slapin | it can be made less intrusive. |
| 15:51.03 | slapin | Marex: 乾杯 |
| 15:51.09 | slapin | ! |
| 15:52.13 | slapin | got a 9 litre of some bad whikey for new year present |
| 15:58.25 | penguin42 | 9 litres? |
| 15:59.42 | slapin | penguin42: yes |
| 16:00.37 | slapin | penguin42: people think if this as a way to show how thankful they are |
| 16:00.58 | slapin | s/if this/of this/ |
| 16:01.48 | slapin | so normal bottle was not enough |
| 16:02.10 | slapin | I'd better get money they wasted on this |
| 16:04.01 | slapin | by the way, I've installed youtube on mk802ii back. So it is possible. |
| 16:04.44 | slapin | first of all it doesn't support adb (no usb gadget) and is not detected by USB at all. |
| 16:05.09 | slapin | so I had to use android's terminal and android's pm to do that |
| 16:06.05 | slapin | so I found package on some site in Internet (as found no way to download this from market), and installed it using pm. |
| 16:06.40 | slapin | while insalling from market always fails with package format is invalid error, this way worked. |
| 16:07.18 | slapin | but another thing - lots of packages won't install because of certificates problem, which I have not solved yet. |
| 16:08.18 | slapin | Android thing is more fragile than I thought. But as device to play kid's cartoons from youtube it works now, so I won't touch it anymore |
| 16:08.38 | slapin | as I have lots of other sticks to play with |
| 16:15.51 | Dessimat0r | is Android 4.0.4 on sunxi 3.4 possible or am I wasting my time? |
| 16:16.11 | Dessimat0r | should i be using 3.0 instead? |
| 16:16.25 | Dessimat0r | or some other repo (the allwinner?) |
| 16:42.01 | zoobab | hi |
| 16:44.01 | slapin | The A10 is an A8, same as the A10s and A13, but the |
| 16:44.02 | slapin | A13 is less than the A10 but larger and A10s is not the plural of A10. |
| 16:44.04 | slapin | And the A20 been like an A10 but A7 |
| 16:44.08 | slapin | so nice |
| 16:44.15 | slapin | thanks, mnemoc |
| 16:44.28 | slapin | first good laugh this day |
| 16:45.50 | specing | cortex-a9001 |
| 16:51.08 | buZz | slapin: where did you copy that from? :P |
| 16:52.52 | slapin | buZz: linux-arm-kernel |
| 16:52.58 | buZz | ML? |
| 16:53.05 | slapin | buZz: yes |
| 17:05.17 | *** join/#arm-netbook eebrah (~chatzilla@212.49.88.111) |
| 17:07.37 | ssvb | rz2k: do you know if Qualcomm's EXA is providing a useful acceleration? |
| 17:08.48 | ssvb | rz2k: with "acceleration" I mean "actual performance" |
| 17:12.16 | ssvb | rz2k: quoting the guy who has implemented the only properly accelerated 2D driver for X11, "EXA is a mere midlayer whose existence is to hinder the driver from doing the right thing" - http://ickle.wordpress.com/2012/08/01/in-the-beginning/ |
| 17:12.33 | buZz | lol |
| 17:15.59 | rz2k | no, I didnt know that |
| 17:19.58 | rz2k | I linked that driver as an example of wiring EXA to some sort of ASIC 2D acceleration |
| 17:20.04 | rz2k | no idea if it works or not |
| 17:20.39 | rz2k | I wouldnt be surprised if G2D that we have in sun4i is a stolen IP from somewhere |
| 17:21.33 | ssvb | rz2k: EXA is not bad as a convenience layer and is actually relatively easy to use, it could rely on G2D's own memory allocator in the reserved memory area for the "video memory", or maybe UMP could be used instead |
| 17:22.07 | jelly-home | ssvb: I remember when XAA was the norm and Render extension was fresh, the Xig people and their commercial X implementation had like 20-100 times better render performance and basically spit on X.org |
| 17:22.31 | penguin42 | anyone know much about the rockschip RK3066? |
| 17:22.36 | jelly-home | (on an i915, if I remember correctly) |
| 17:22.41 | penguin42 | seems to be landing in the new batch of cheapo android things |
| 17:22.49 | penguin42 | (Dual core A9, Mali-400) |
| 17:22.59 | rz2k | ssvb: g2d's allocator is allwinner-style crap, I guess? |
| 17:23.04 | slapin | penguin42: damn bad USB connector on mine, solder it third time |
| 17:23.19 | penguin42 | slapin: haha ok, but that's not the chip |
| 17:23.26 | slapin | penguin42: as usual, promising hardware, bad software, lots of blobs |
| 17:23.53 | penguin42 | sounds normal |
| 17:24.06 | rm | penguin42, the AMLogic dual-core is holding on par with the RK3066 |
| 17:24.07 | ssvb | rz2k: I'm not so sure about UMP, because it must a) allocate physically contiguous memory and b) report the physical memory address to the userspace (if we initially don't care about the security and just want to have something up and running) |
| 17:24.23 | rm | both in price and in performance; and it seems to be somewhat more open |
| 17:24.47 | rm | don't exactly remember where I got that impression from ._. |
| 17:25.13 | rz2k | ssvb: there was some security in UMP, though |
| 17:25.27 | rz2k | protecting each allocation with security ID |
| 17:26.02 | ssvb | rz2k: and of course c) it must be non-swappable just to be sure that the pixmap memory is always there |
| 17:27.36 | ssvb | rz2k: yes, the G2D allocator is a good example of bad code, and of course G2D has serious security issues right now :) |
| 17:28.11 | rm | penguin42, http://www.cnx-software.com/2012/10/10/droid-stick-a2-amlogic-aml8726-mx-dual-core-android-4-1-1-mini-pc/ |
| 17:28.30 | rz2k | ssvb: could you please, if you have time, document your findings and guidelines for future coding @ wiki? |
| 17:28.46 | *** join/#arm-netbook Avernos (~avernos@114.245.250.169) |
| 17:28.47 | *** join/#arm-netbook Avernos (~avernos@unaffiliated/avernos) |
| 17:29.48 | rz2k | G2D page is empty right now, Mali400 page contains only info about installation and libs that we have right now. |
| 17:30.29 | penguin42 | rm: Looks like there is rk3066 code on the net |
| 17:31.06 | ssvb | rz2k: in any case, I think it's a good idea to just forget about xf86-video-mali right now and concentrate on implementing a demo based on g2d client side acceleration in cairo/pixman |
| 17:31.16 | *** join/#arm-netbook ph0en1x (~ph0en1x@c-98-210-135-53.hsd1.ca.comcast.net) |
| 17:31.49 | ssvb | rz2k: do you mean documentation about g2d driver code? or about the hardware? |
| 17:32.04 | rz2k | about what we have now/what to do next |
| 17:32.30 | rz2k | people tend to not read the IRC logs :) |
| 17:34.24 | ph0en1x | hey all - so can anyone tell me if the rpi's usb uart ttl cables work with the mk802 or mk802iii? |
| 17:36.15 | slapin | ssvb: if you implement pixman's acceleration, you will have X11 accelerated fast enough to work |
| 17:37.35 | ph0en1x | something like this: https://www.olimex.com/Products/Components/Cables/USB-Serial-Cable/USB-Serial-Cable-F/ |
| 17:38.05 | ph0en1x | s/ttl/tty/ |
| 17:38.54 | ssvb | slapin: yes, that's the plan :) |
| 17:40.39 | ph0en1x | yeah, i'm also interested in getting a dev vm set up so i can help out ;) |
| 17:43.54 | ssvb | slapin: though memory allocation/management is going to be a PITA and the biggest challenge for properly interoperating with xf86-video-mali |
| 17:48.29 | ssvb | rz2k: not sure about the wiki and writing any kind of guidelines there, I'm primarily a software acceleration guy who is only trying to get started with the hardware acceleration stuff |
| 17:50.42 | ssvb | rz2k: even though I find the current hardware acceleration for X11 really messed up, the hardware acceleration professionals may have a different opinion |
| 17:51.28 | buZz | i would really really like for mali-400 to become a lot faster |
| 17:51.33 | buZz | and i feel there is room for this |
| 17:51.43 | buZz | but unfortunately i am no driver whizz |
| 18:11.05 | *** join/#arm-netbook eFfeM (~frans@c73189.upc-c.chello.nl) |
| 18:40.23 | *** join/#arm-netbook dfletcher (~fletch@108-196-222-251.lightspeed.sntcca.sbcglobal.net) |
| 18:40.31 | *** join/#arm-netbook dfletcher (~fletch@drupal.org/user/72475/view) |
| 18:43.48 | *** join/#arm-netbook ibot (~ibot@rikers.org) |
| 18:43.48 | *** topic/#arm-netbook is EOMA: Embedded Open Modular Architecture - Don't ask to ask. Just ask! - http://elinux.org/Embedded_Open_Modular_Architecture/EOMA-68 - ML arm-netbook@lists.phcomp.co.uk - Logs http://ibot.rikers.org/%23arm-netbook or http://irclog.whitequark.org/arm-netbook/ - http://rhombus-tech.net/ |
| 18:56.33 | *** join/#arm-netbook lerc (~quassel@121-74-240-231.telstraclear.net) |
| 19:03.06 | *** join/#arm-netbook toxicpsion (~toxicpsio@h216-45-98-25.dynamic.platinum.ca) |
| 19:07.38 | *** join/#arm-netbook _whitelogger (whitelogge@fehu.whitequark.org) |
| 19:48.15 | *** join/#arm-netbook eFfeM (~frans@c73189.upc-c.chello.nl) |
| 19:57.32 | *** join/#arm-netbook gsilvis (~almostsix@50.12.163.241) |
| 19:58.51 | *** join/#arm-netbook eFfeM1 (~frans@c73189.upc-c.chello.nl) |
| 20:06.16 | *** join/#arm-netbook eFfeM (~frans@c73189.upc-c.chello.nl) |
| 20:08.38 | ssvb | jelly-home: when XAA was the norm, Render extension was done in software with a rather trivial/simplistic code (like doing function callbacks per each pixel) and 20-100 times performance difference is not surprising |
| 20:09.48 | ssvb | jelly-home: nowadays software rendering is significantly faster, got SIMD optimizations and can even challenge the hardware accelerated drivers |
| 20:10.13 | *** join/#arm-netbook Avernos (~avernos@unaffiliated/avernos) |
| 20:10.54 | *** join/#arm-netbook eebrah (~chatzilla@212.49.88.96) |
| 20:11.29 | ssvb | jelly-home: the video from http://www.phoronix.com/scan.php?page=news_item&px=MTE4OTc explains the current state of the art 2D hardware acceleration |
| 20:11.42 | *** join/#arm-netbook eFfeM1 (~frans@c73189.upc-c.chello.nl) |
| 20:11.42 | *** join/#arm-netbook Skoti_ (589cdff4@gateway/web/freenode/ip.88.156.223.244) |
| 20:27.08 | *** join/#arm-netbook whitequark (whitequark@fehu.whitequark.org) |
| 20:27.20 | whitequark | added colored nicks to the logger! http://irclog.whitequark.org/arm-netbook/ |
| 20:38.00 | *** join/#arm-netbook eFfeM (~frans@c73189.upc-c.chello.nl) |
| 20:42.20 | *** join/#arm-netbook eFfeM1 (~frans@c73189.upc-c.chello.nl) |
| 20:50.27 | rz2k | yay! |
| 20:56.48 | penguin42 | oh a very tasteful green |
| 21:01.35 | buZz | what color am i? :D |
| 21:01.57 | buZz | yellow! |
| 21:01.58 | buZz | w000t |
| 21:02.02 | buZz | nice and positive \o/ |
| 21:22.04 | ssvb | I'm also yellow. I guess there are not enough unique colors for everyone :-/ |
| 21:55.50 | buZz | ssvb: there is just so many colors in a 24bit palette, sorry :P |
| 21:58.02 | RaYmAn | color could be first 4 bytes of the md5 sum of the persons nick :D (honestly, aren't we past "websafe" colors" ;)) |
| 21:59.55 | ssvb | buZz: :) |
| 22:00.48 | whitequark | it's crc32(nick)%16 |
| 22:01.21 | whitequark | most colors where anyof(r,g,b)<55 are unreadable |
| 22:01.38 | RaYmAn | Details! :P |
| 22:01.42 | whitequark | plus not having a consistently spaced palette doesn't quite read as good as text with a fixed one |
| 22:02.01 | whitequark | so I just chose 16 nice pastel colors and map nicks to them with the above function |
| 22:02.12 | whitequark | RaYmAn: read the source, Luke |
| 23:20.03 | *** join/#arm-netbook toxicpsion_ (~toxicpsio@h216-45-98-25.dynamic.platinum.ca) |
