| 00:20.32 | *** join/#arm-netbook qubits (~nul@ip-64-134-142-102.public.wayport.net) |
| 00:20.33 | *** join/#arm-netbook qubits (~nul@unaffiliated/qubits) |
| 01:02.46 | *** join/#arm-netbook ZaEarl (~malmrose@c-24-6-238-36.hsd1.ca.comcast.net) |
| 01:10.15 | *** join/#arm-netbook avernos (~avernos@221.223.239.42) |
| 01:10.16 | *** join/#arm-netbook avernos (~avernos@unaffiliated/avernos) |
| 01:54.33 | *** join/#arm-netbook revident (~scott@fw.ss.org) |
| 02:26.24 | *** join/#arm-netbook ZaEarl (~malmrose@c-24-6-238-36.hsd1.ca.comcast.net) |
| 02:28.42 | *** join/#arm-netbook Turl (~Turl@2606:3f00:60:21c:d00d:c0de:4:f00d) |
| 03:18.33 | *** join/#arm-netbook Quarx (~Quarx@94.137.35.24) |
| 03:40.10 | *** join/#arm-netbook qubits (~nul@68.68.22.151.customer.bluemilenetworks.com) |
| 03:40.10 | *** join/#arm-netbook qubits (~nul@unaffiliated/qubits) |
| 03:53.20 | *** join/#arm-netbook mSquare (~selvan@122.167.104.210) |
| 04:26.06 | *** join/#arm-netbook ZaEarl (~malmrose@c-24-6-238-36.hsd1.ca.comcast.net) |
| 05:15.38 | eflatun | techn are you awake |
| 05:30.14 | *** join/#arm-netbook ejstacey (~ejstacey@milkman.joyrex.net) |
| 06:06.10 | *** join/#arm-netbook jinzo_ (~jinzo@oxy.p2p.si) |
| 06:25.30 | *** join/#arm-netbook qubits (~nul@unaffiliated/qubits) |
| 06:31.45 | *** join/#arm-netbook rellla (~Thunderbi@p5B0788AD.dip0.t-ipconnect.de) |
| 06:42.40 | *** join/#arm-netbook eflatun (~eflatun@46.1.238.41) |
| 07:04.23 | *** join/#arm-netbook pawel5870 (~pkarpins@pc.193147149.ip.amg.net.pl) |
| 07:19.06 | *** join/#arm-netbook cat_n9 (~communi@80-186-41-132.elisa-mobile.fi) |
| 07:25.31 | *** join/#arm-netbook qubits (~nul@unaffiliated/qubits) |
| 07:31.12 | *** join/#arm-netbook rellla (~Thunderbi@p5B079385.dip0.t-ipconnect.de) |
| 07:44.51 | *** join/#arm-netbook sspiff (~quassel@unaffiliated/yukito) |
| 08:01.19 | zoobab | hello |
| 09:16.25 | hno | morning |
| 09:22.44 | mnemoc | morning hno |
| 09:27.08 | hno | got the sun4i/sun5i DRAM controller differences identified nicely now. It's quite manageable to use the same code on both. https://github.com/hno/Allwinner-Info/blob/master/A13/boot/sun5i.diff |
| 09:29.48 | hno | now I just need to decice if I am going with Allwinners code, or the code Tom wrote for A10. Quite different coding style. |
| 09:33.32 | mnemoc | what makes you want to switch bases from hipboi's mmc to lichee-dev at this point? |
| 09:35.13 | zoobab | ordering the olimex a13 board |
| 09:37.21 | mnemoc | zoobab: btw, there is an #olimex channel too |
| 09:37.38 | mnemoc | great they found how to fix the VGA colors problem |
| 09:39.38 | zoobab | yop |
| 09:39.53 | zoobab | is there a gentoo port for the a13 yet? |
| 09:40.27 | mnemoc | there are a bunch of Gentoo fans here, but afaik they haven't published related anything yet |
| 09:42.09 | *** join/#arm-netbook eflatun (~eflatun@46.1.137.203) |
| 09:42.09 | hno | mnemoc, ofcourse not. Only talking about the dram code. See dram-sun4i.c vs dram-sun5i.c. |
| 10:40.47 | *** join/#arm-netbook cat_n9 (~communi@a91-152-66-200.elisa-laajakaista.fi) |
| 11:08.13 | *** join/#arm-netbook qubits (~nul@c-50-135-120-247.hsd1.wa.comcast.net) |
| 11:08.13 | *** join/#arm-netbook qubits (~nul@unaffiliated/qubits) |
| 11:23.15 | *** join/#arm-netbook itamarjp (~itamar@fedora/itamarjp) |
| 11:25.25 | *** join/#arm-netbook mysteryname (~mysteryna@14-202-9-167.tpgi.com.au) |
| 11:28.25 | jinzo_ | zoobab, specing has fiddled with A10 "port" a bit afaik. He didn't publish anything specific but linked me to the linux-sunxi wiki. |
| 11:31.42 | mnemoc | http://linux-sunxi.org/Gentoo still empty :'( |
| 11:32.02 | jinzo_ | room for improvement! :) |
| 11:32.11 | mnemoc | plenty :) |
| 11:50.35 | zoobab | will start some binhost+gentoo overlay for a10 |
| 11:50.53 | zoobab | sabayon has some nice binaries for beaglebone |
| 11:51.10 | zoobab | it is nice because I do not want to compile on the machine itself |
| 11:53.08 | *** join/#arm-netbook rellla1 (~Thunderbi@p4FE56190.dip0.t-ipconnect.de) |
| 11:53.40 | *** join/#arm-netbook qubits (~nul@unaffiliated/qubits) |
| 11:54.27 | *** join/#arm-netbook hipboi (~hipboi@123.64.149.125) |
| 12:21.47 | *** join/#arm-netbook Almamuetya (~almamuety@186.134.8.195) |
| 12:23.25 | *** join/#arm-netbook cat_n9 (~communi@81-197-2-190.elisa-mobile.fi) |
| 12:42.12 | *** join/#arm-netbook phh_ (~quassel@137.194.15.151) |
| 13:36.36 | *** join/#arm-netbook von_fritz (~fritz@host21-184-dynamic.54-82-r.retail.telecomitalia.it) |
| 14:03.09 | *** join/#arm-netbook cheng (~cheng@175.137.64.19) |
| 14:21.02 | *** join/#arm-netbook revident (~scott@fw.iplink.net) |
| 14:30.34 | *** join/#arm-netbook zenitraM_ (~zenitraM@2607:f358:1:fed5:11:0:1018:14) |
| 14:31.24 | *** join/#arm-netbook rsalveti (~rsalveti@linaro/rsalveti) |
| 14:31.33 | *** join/#arm-netbook destinal (destinal@unaffiliated/destinal) |
| 14:32.09 | *** join/#arm-netbook cat_n9 (~communi@a91-152-66-200.elisa-laajakaista.fi) |
| 14:49.28 | *** join/#arm-netbook rsalveti (~rsalveti@177.133.172.114) |
| 14:49.28 | *** join/#arm-netbook rsalveti (~rsalveti@linaro/rsalveti) |
| 14:59.49 | *** join/#arm-netbook rsalveti (~rsalveti@177.133.172.114) |
| 14:59.49 | *** join/#arm-netbook rsalveti (~rsalveti@linaro/rsalveti) |
| 15:04.44 | *** part/#arm-netbook cheng (~cheng@175.137.64.19) |
| 15:05.24 | *** join/#arm-netbook rsalveti (~rsalveti@177.133.172.114) |
| 15:05.25 | *** join/#arm-netbook rsalveti (~rsalveti@linaro/rsalveti) |
| 15:07.27 | *** join/#arm-netbook pawel58701 (~pkarpins@public-gprs75211.centertel.pl) |
| 15:08.39 | *** join/#arm-netbook cat1 (~cat_x301@a91-152-66-200.elisa-laajakaista.fi) |
| 15:14.39 | *** join/#arm-netbook cat1 (~cat_x301@a91-152-66-200.elisa-laajakaista.fi) |
| 15:19.02 | *** join/#arm-netbook e-ndy- (~e-ndy@fantomas.bestit.cz) |
| 15:20.26 | *** join/#arm-netbook Kraln- (~kraln@69.169.90.239) |
| 15:22.00 | *** join/#arm-netbook CIA-9 (~CIA@cia.vc) |
| 15:23.35 | *** join/#arm-netbook robws (~robws1@38.99.170.111) |
| 15:23.55 | *** join/#arm-netbook avernos (~avernos@unaffiliated/avernos) |
| 15:25.22 | *** join/#arm-netbook Thomas42 (~Thomas42@static.105.236.9.5.clients.your-server.de) |
| 15:28.15 | *** join/#arm-netbook rsalveti (~rsalveti@177.133.172.114) |
| 15:28.15 | *** join/#arm-netbook rsalveti (~rsalveti@linaro/rsalveti) |
| 15:32.33 | *** join/#arm-netbook CIA-8 (cia@cia.vc) |
| 15:32.40 | *** join/#arm-netbook L84Supper (~ly@unaffiliated/l84supper) |
| 15:59.13 | steev | man fuck xda |
| 15:59.26 | steev | THIS THREAD WAS CLOSED BECAUSE OF WAREZ |
| 15:59.28 | steev | wat? |
| 16:00.12 | RaYmAn | presumably there was warez in the thread :P |
| 16:00.49 | traeak | heh |
| 16:01.34 | *** join/#arm-netbook cat_n9 (~communi@81-197-108-137.elisa-mobile.fi) |
| 16:02.02 | steev | i've read through all 17 pages |
| 16:02.11 | steev | there is no MODEDIT anywhere aside from the main post |
| 16:02.49 | steev | in fact, all the links are still in the thread, just the main post is modified (and the links are the same in the other posts in the thread) |
| 16:03.04 | steev | it was also the only place to get a working CM10 for the LY-F1 without any hassles |
| 16:04.11 | *** join/#arm-netbook rsalveti (~rsalveti@186.214.94.103) |
| 16:04.11 | *** join/#arm-netbook rsalveti (~rsalveti@linaro/rsalveti) |
| 16:04.55 | revident | steev, if that CM10 image was distributing proprietary drivers (in a manner that would violate licensing of them) then I could see that as valid reason for them to cut it off. Was that the case? |
| 16:05.31 | RaYmAn | usually xda is pretty lenient on drivers |
| 16:05.35 | steev | revident: no more proprietary than the usual drivers for android |
| 16:05.49 | RaYmAn | because they are considered required + the person flashing them already has a legal copy on his/her device |
| 16:05.50 | steev | either way, i was never really a fan of xda, now i don't have to go back ever |
| 16:05.54 | RaYmAn | It's more likely GPL related |
| 16:06.25 | steev | and i got the download link from futher in the thread, because mod was a dumbass |
| 16:06.54 | steev | unless they've gone through and massively removed all links to roms |
| 16:09.57 | rz2k | hno: |
| 16:10.04 | rz2k | [ 64.830] GET_UMP_SECURE_ID_BUF1 returned 0x1 offset: 0 virt address: 0x40692000 fb_virt: 0x40692000 [ 64.830] GET_UMP_SECURE_ID_BUF2 returned 0xffffffff offset: 8294400 virt address: (nil) fb_virt: 0x40692000 |
| 16:10.15 | rz2k | is this okay for ump stuff? |
| 16:10.39 | rz2k | this is with your commit about splitting disp/ump |
| 16:14.10 | *** join/#arm-netbook tzafrir_laptop (~tzafrir@bzq-218-155-148.cablep.bezeqint.net) |
| 16:18.37 | steev | revident: actually the interesting thing was, the only link that i'd really consider questionable was the link to the gapps (which was left unedited) |
| 16:19.38 | RaYmAn | steev: they often use the warez label if the author refuses to live up to GPL (at least, I've seen that in other threads) |
| 16:20.16 | steev | why not call it what it properly is then? CLOSED FOR FAILURE TO COMPLY WITH THE GPL |
| 16:20.26 | RaYmAn | probably legacy I guess |
| 16:20.27 | steev | then people would get educated about it |
| 16:20.35 | steev | legacy is no reason to continue idiocy |
| 16:22.13 | RaYmAn | shrugs |
| 16:22.20 | rz2k | also another question, mali x11 has this define https://github.com/rzk/Mali-400-r3p0-04rel0-X11-drivers/blob/master/src/mali_def.h#L46 does it reflect our setup right? I mean https://github.com/amery/linux-allwinner/blob/wip/linux-sunxi-3.0/next_mali/drivers/video/sunxi/disp/disp_ump.c#L26 |
| 16:22.21 | RaYmAn | I was just communication what I've seen happen :P |
| 16:22.48 | *** join/#arm-netbook rsalveti (~rsalveti@186.214.94.103) |
| 16:22.48 | *** join/#arm-netbook rsalveti (~rsalveti@linaro/rsalveti) |
| 16:23.15 | steev | RaYmAn: i'm sure, it's still annoying to me that people refuse to educate themselves. they really have a great opportunity with this, and instead associate it with illegally gained software that's usually of questionable nature |
| 16:23.16 | RaYmAn | rz2k: there should be a define identical to that one elsewhere (which then calls the _disp_get_ump_secure_id ) |
| 16:23.38 | RaYmAn | technically speaking, violating GPL is ~warez ;) |
| 16:23.44 | steev | no, it isn't |
| 16:24.02 | traeak | so playing with android steev ? |
| 16:24.05 | steev | unless you're trying to argue stealing is stealing |
| 16:24.16 | RaYmAn | In both cases, you violate the copyright holders Copyright and hence their License. |
| 16:24.21 | steev | at which point, taking a pen home from the office ~warez |
| 16:24.39 | traeak | interesting with apple and the a6, it seems that improving the arm core design is a low hanging fruit. I guess arm isn't exactly well known for putting together a tight performance core |
| 16:24.41 | RaYmAn | it only applies to software obviously. |
| 16:24.44 | steev | violating the license isn't stealing the software |
| 16:24.54 | RaYmAn | then warez isn't stealing the software either |
| 16:24.59 | RaYmAn | cause all you do there is violate the license. |
| 16:25.06 | steev | traeak: actually that isn't true |
| 16:25.11 | steev | RaYmAn: really? |
| 16:25.17 | RaYmAn | it's not the process of downloading software that's illegal |
| 16:25.21 | RaYmAn | It's using it without having a valid license. |
| 16:25.27 | RaYmAn | technically speaking |
| 16:25.30 | steev | RaYmAn: so if i "warez" a copy of Maya3d or some other software program that costs 30K USD |
| 16:25.30 | traeak | steev: i was just saying that the jump from armv6 to armv7 was huge |
| 16:25.32 | RaYmAn | it's of course a bit more complicated than that |
| 16:25.43 | RaYmAn | steev: then you are violating the license of the program. |
| 16:25.49 | steev | all i've done is technically violated the license? |
| 16:25.52 | traeak | steev: only speculating that there'd be more low hanging fruit for getting big performance jumps |
| 16:26.03 | steev | traeak: there are 2 different cores available from ARM |
| 16:26.14 | steev | one for performance, one for power.... management |
| 16:26.28 | steev | 90% of companies license the power maangement one |
| 16:27.06 | steev | RaYmAn: wow, if only i'd known that stealing a program "worth" 30K was really only a license violation |
| 16:45.38 | RaYmAn | steev: value has no concept in whether you violate a license or not. |
| 16:45.58 | RaYmAn | obviously, if a program is more expensive, they can argue higher damages. |
| 16:47.20 | RaYmAn | steev: also, I guess it's more license violation => copyright infringement |
| 16:47.22 | steev | RaYmAn: you violate the license both times, the GPL already lists the "damages" possible (you lose your ability to distribute said program) - however, there is no proof that he's violating the GPL, and even if he were, i've seen no one ask him for the sources in the thread at all, and based on messages he seems pretty open about everything. he points to exactly where the work came from and tells |
| 16:47.22 | steev | what the differences are between the two. |
| 16:47.44 | steev | secondly, there's no set time frame for GPL "compliance" - it simply says "in a timely manner" |
| 16:48.27 | steev | Apple, who are a shitload larger than a single developer, take 6-12 months to post their gpl sources |
| 16:48.40 | steev | same for Goog and others, although they've gotten better at it lately |
| 16:49.10 | RaYmAn | IF said issue was GPL violation, the person is more than welcome to post his work elsewhere - XDA are free to decide that not posting sources after a mods ask (for example) => thread close |
| 16:49.59 | RaYmAn | (also, the license/copyrigth infringement vs stealing depends on country really - but either way, if paid software => stealing, surely violating gpl license => stealing) |
| 16:50.50 | steev | we can agree to disagree re: stealing (although i do believe it's wrong), but again, there was no indication whatsoever |
| 16:51.21 | steev | and yeah they are free to close it, but in my eyes they definitely went down a shitload of notches, not that they were particularly high up on the totem pole of sites worth visiting |
| 16:53.50 | RaYmAn | as I said wrt stealing, it varies by country. In my country it's not legally classified as stealing, but as copyright infringement. |
| 16:54.21 | RaYmAn | (which makes it a civil suit) |
| 16:58.38 | hno | rz2k, no idea how it works or what is valid. |
| 16:59.06 | techn | rz2k: hno: found bug. int should be unsigned int? |
| 16:59.10 | *** join/#arm-netbook cat_n9 (~communi@a91-152-66-200.elisa-laajakaista.fi) |
| 16:59.25 | rz2k | hno: https://github.com/rzk/Mali-400-r3p0-04rel0-X11-drivers/blob/master/src/mali_exa.c#L192 these ioctls are not defined in disp_fb |
| 16:59.49 | rz2k | I'm trying to find any docs about integration :/ |
| 17:00.18 | rz2k | readme says only about first one, that we already have. https://github.com/amery/linux-allwinner/blob/bd7c9b5e2487c3f65a21d3992b1081995879e3ee/drivers/video/sunxi/disp/dev_fb.c#L1117 |
| 17:00.36 | rz2k | s/first one/GET_UMP_SECURE_ID/ |
| 17:02.16 | *** join/#arm-netbook eflatun (~eflatun@46.1.25.181) |
| 17:03.44 | hno | rz2k, i would think the other two are on the ump device. |
| 17:03.47 | rz2k | techn: addr changed, [ 3263.481] GET_UMP_SECURE_ID_BUF1 returned 0x1 offset: 0 virt address: 0x4069a000 fb_virt: 0x4069a000 [ 3263.487] GET_UMP_SECURE_ID_BUF2 returned 0xffffffff offset: 8294400 virt address: (nil) fb_virt: 0x4069a000 [ 3263.488] (EE) MALI(0): [maliModifyPixmapHeader:205] UMP failed to retrieve secure id |
| 17:04.03 | hno | which is scary if they use plain intewgers 1-n. |
| 17:13.05 | hno | rz2k, do you get the same error if run twice? |
| 17:13.45 | rz2k | run twice = ? I've restarted xorg many times from device powerup |
| 17:13.51 | hno | the split changes order a bit, registering the framebuffer memory in ump on first GET_SECURE_ID request. |
| 17:14.36 | rz2k | mm, probably thats not the case, this is like 10th or something close start of xorg |
| 17:18.16 | rz2k | if anyone want to test, you can git clone https://github.com/rzk/Mali-400-r3p0-04rel0-X11-drivers. I've included simple build.sh |
| 17:19.19 | RaYmAn | I was under the impression that you needed to have the DDK to build those drivers |
| 17:19.36 | hno | RaYmAn, you need the libraries that is built from the DDK. |
| 17:20.01 | rz2k | yes, libmali/libump |
| 17:20.15 | RaYmAn | ah, that explains it |
| 17:20.17 | rz2k | libump can be built from public sources from malideveloper.com |
| 17:20.26 | rz2k | libmali is proprietary :( |
| 17:25.31 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 17:25.52 | *** join/#arm-netbook Hexxeh (u1532@gateway/web/irccloud.com/x-fkylmqwffwzgursu) |
| 17:29.28 | *** join/#arm-netbook xxiao1 (~xxiao@ec2-50-112-57-59.us-west-2.compute.amazonaws.com) |
| 17:33.44 | *** join/#arm-netbook avernos (~avernos@221.223.233.24) |
| 17:33.45 | *** join/#arm-netbook avernos (~avernos@unaffiliated/avernos) |
| 17:44.59 | rz2k | hno: |
| 17:45.13 | rz2k | I cant find buf1/2 ioctls in ump |
| 17:45.37 | rz2k | this might mean that we really miss them. |
| 17:50.57 | techn | rz2k: buf1 ioctl is same as SECURE_ID |
| 17:53.02 | hno | which is odd if they are on same device |
| 17:53.08 | *** join/#arm-netbook sspiff (~quassel@d8D862466.access.telenet.be) |
| 17:53.09 | *** join/#arm-netbook sspiff (~quassel@unaffiliated/yukito) |
| 17:53.56 | hno | rz2k, any hints if looking in snowball kernel sources? |
| 17:54.14 | rz2k | they thrown ump out and use hwmem device |
| 17:54.15 | hno | that's the only MALI I know of with working X11 drivers. |
| 17:56.29 | rz2k | http://www.igloocommunity.org/gitweb/?p=android/platform/vendor/st-ericsson/multimedia/linux/mali400ko.git;a=commit;h=74bf0fbc69fd6a8fa9f15ce74c1dfa96c2090202 |
| 17:57.47 | rz2k | also r2p4 doesnt have these ioctls, only get_secure_id |
| 18:01.26 | *** join/#arm-netbook gimli_ (~gimli@xbmc/staff/gimli) |
| 18:02.29 | RaYmAn | hno: Samsung Origen? iirc that's Mali400 as well and linaro has builds for Linux on that |
| 18:08.02 | RaYmAn | hno: hmm, no..Looks like they are having issues getting hwgfx working on origin as well |
| 18:10.35 | *** join/#arm-netbook cat_n9 (~communi@80-186-219-92.elisa-mobile.fi) |
| 18:14.05 | *** join/#arm-netbook bsdfox (~Bob@unaffiliated/bsdfox) |
| 18:14.10 | hno | rz2k, where are the ioctls defined again? |
| 18:14.48 | bsdfox | hey I just got my A2000 this morning and I'm trying to figure out how to boot ubuntu on it. I dd the image to an sd card stick it in and power it up but I get no video. pull the card out and it boots to android |
| 18:14.49 | rz2k | https://github.com/rzk/Mali-400-r3p0-04rel0-X11-drivers/blob/master/src/mali_def.h#L46 usage: https://github.com/rzk/Mali-400-r3p0-04rel0-X11-drivers/blob/master/src/mali_exa.c#L192 |
| 18:15.23 | RaYmAn | bsdfox: I'd recommend getting serial going |
| 18:15.29 | hno | So in header for X11 driver? Gah... ioctls should be in kernel headers. |
| 18:15.49 | RaYmAn | hno: they need to be in both really :P |
| 18:16.00 | RaYmAn | unless you want the driver to depend on the kernel for compilation |
| 18:16.20 | bsdfox | RaYmAn, is there no video on these ubuntu images? |
| 18:16.38 | hno | ofcourse. you pick them from the kernel driver when building the userspace component. |
| 18:16.53 | RaYmAn | bsdfox: there is, but it'll help you figure out why it's failing |
| 18:17.19 | hno | having copies floating around everywhere just causes mismatches. |
| 18:17.39 | rz2k | r3p1 has same ioctls |
| 18:17.54 | rz2k | so no hope for new version to fix this |
| 18:18.02 | hno | r3p1 of what? |
| 18:18.15 | rz2k | r3p1 of x11/dri2/exa drivers for mali400 |
| 18:18.38 | techn | bsdfox: http://forum.doozan.com/read.php?6,9527 |
| 18:19.12 | rz2k | and I've diff'ed UMP and Mali400 in our next_mali branch with r3p0 from malideveloper, its 1:1. |
| 18:19.20 | rz2k | (except config.h for a10) |
| 18:19.53 | hno | we are at r3p0, right? |
| 18:19.57 | rz2k | yes |
| 18:21.53 | techn | rz2k: how it tries to get BUF2.. I wont get it :/ |
| 18:23.27 | rz2k | mm, dumb idea probably, but mali r3p0 seems to introduce two framebuffers support with this |
| 18:23.42 | rz2k | (mali_drv in DRM has support for two too) |
| 18:24.15 | hno | But why do they need two ioctls when these are called on the framebuffer? |
| 18:24.49 | *** join/#arm-netbook ZaEarl (~malmrose@173-11-125-162-SFBA.hfc.comcastbusiness.net) |
| 18:25.03 | rz2k | no idea, another ARM-style crap code maybe? |
| 18:25.17 | rz2k | because they left include to ../../../../devicedrv/ |
| 18:25.25 | rz2k | in release version for public |
| 18:26.08 | *** join/#arm-netbook hp_ (~kvirc@188.188.46.133) |
| 18:26.13 | hno | and README.txt do not even reflect the right location where the ioctls are defined. |
| 18:27.40 | rz2k | interesting that GET_UMP_SECURE_ID_BUF1 should retrive secure_id as just GET_UMP_SECURE_ID as techn said, but on my mele with next_mali kernel and modules secure_id = 1 which is define for UMP_INVALID_SECURE_ID |
| 18:28.03 | rz2k | so even if the x11 driver is broken, we still have our disp-ump broken, lol. |
| 18:28.57 | hno | Seems they are the same. _BUF1 == the original for first framebuffer, and _BUF2 the new for second framebuffer. |
| 18:29.17 | hno | The original one is no longer used. |
| 18:30.56 | techn | hno: I think _BUF2 is backbuffer |
| 18:31.21 | techn | so they implemented somekind doublebuffering? |
| 18:32.06 | hno | techn, yes seems so on a second reading. |
| 18:32.56 | techn | .. but README says that virtual xres should be 2*xres <- which is orginal double buffering mechanism? :/ |
| 18:34.58 | rz2k | [ 3263.493] (II) MALI(0): Changing mode to 1024 768 1024 1536 |
| 18:35.03 | rz2k | it actually does it |
| 18:35.32 | *** join/#arm-netbook merbzt (~benjamin@c-94-255-220-30.cust.bredband2.com) |
| 18:36.40 | *** join/#arm-netbook cat_n9 (~communi@a91-152-66-200.elisa-laajakaista.fi) |
| 18:38.07 | hno | rz2k, the _BUF2 usage is here: https://github.com/rzk/Mali-400-r3p0-04rel0-X11-drivers/blob/master/src/mali_exa.c#L230 |
| 18:38.16 | hno | between offset = size and offset = 0 |
| 18:40.32 | techn | hno: how is maliModifyPixmapHeader even called? |
| 18:40.39 | techn | or where |
| 18:41.09 | rz2k | so, this means that we need to create another virtual framebuffer not linked to any device and introduce get_secure_id there? |
| 18:41.21 | hno | No idea what it means |
| 18:41.42 | techn | MALI_EXA_FUNC(ModifyPixmapHeader); |
| 18:44.06 | techn | rz2k: try to add that _BUF2 implementation to disp-fb? :) |
| 18:46.12 | mnemoc | please don't make disp-fb depend on ump :( |
| 18:47.54 | RaYmAn | mnemoc: that can always be refactored nicely once it works though ;) |
| 18:48.03 | mnemoc | RaYmAn: true :) |
| 18:48.59 | rz2k | techn: will try tomorrow. |
| 18:51.19 | techn | hmm.. should ump_memory_description.size = info->fix.smem_len; be divided by 2 |
| 18:51.54 | techn | and _BUF1 gets first half and _BUF2 second |
| 19:10.20 | *** join/#arm-netbook rellla (~Thunderbi@p4FE56190.dip0.t-ipconnect.de) |
| 19:11.46 | hno | techn, no idea. |
| 19:12.39 | hno | better ask in the malideveloper forum. |
| 19:19.16 | bsdfox | RaYmAn, is the serial this white connector in the middle front? |
| 19:19.45 | RaYmAn | bsdfox: sorry, don't have a mele. Check the wiki |
| 19:23.08 | mnemoc | bsdfox: the serial is a 4pin header between the DRAM and you |
| 19:24.07 | bsdfox | cool |
| 19:24.10 | bsdfox | what's default baud? |
| 19:24.15 | mnemoc | 115200 |
| 19:25.21 | bsdfox | that's working. thanks |
| 19:37.47 | mnemoc | yw |
| 19:38.53 | bsdfox | hmm it boots to a console I just get no video (at least on hdmi) |
| 19:39.18 | bsdfox | root@linaro-server:~# uname -a |
| 19:39.18 | bsdfox | Linux linaro-server 3.0.31+ #1 PREEMPT Thu Jun 21 20:16:20 ICT 2012 armv7l armv7l armv7l GNU/Linux |
| 19:39.44 | mnemoc | back then there was no fbcon |
| 19:40.08 | mnemoc | also, to run X you might need to load the modules |
| 19:40.15 | bsdfox | hmm I thought I got the newest build for a1000/2000 |
| 19:40.40 | xxiao1 | http://venturebeat.com/2012/09/15/hardware-is-dead/ |
| 19:40.59 | xxiao1 | "Most of these designs are powered by a processor from a company that is not known outside China — All Winner. " |
| 19:41.06 | xxiao1 | the $45 table story... |
| 19:41.15 | xxiao1 | s/table/tablet/ |
| 19:42.23 | mnemoc | bsdfox: also judging by the hostname you might have all the display related stuff disabled (to save memory for server usage) |
| 19:44.07 | bsdfox | anyone know of a good build I can download? |
| 19:44.49 | mnemoc | people usually suggests to use cnxsoft's nightly builds |
| 19:45.17 | mnemoc | but I believe most of the people active in this channel makes their own |
| 19:45.29 | mnemoc | instead of dumping a pre-made image |
| 19:46.03 | bsdfox | I guess I can setup a cross compiler |
| 19:46.13 | techn | I'm using cnxsoft's scripts to make my own |
| 19:46.56 | mnemoc | bsdfox: http://dl.linux-sunxi.org/nightly/latest/ |
| 19:47.15 | mnemoc | bsdfox: and the corresponding docu. http://www.cnx-software.com/2012/07/20/nightly-builds-for-allwinner-a10-u-boot-linux-kernel-and-hardware-packs/ |
| 19:47.26 | bsdfox | thanks |
| 20:01.00 | hno | techn & rz2k posted a question about the new ioctl in arms mali driver forum at http://forums.arm.com/index.php?/topic/16220-what-is-get-ump-secure-id-buf2-ioctl/ |
| 20:01.27 | techn | thanks |
| 20:03.53 | hno | Hmm... probably should update my gravatar.. don't quite look like me any more. |
| 20:06.21 | mnemoc | techn: have you been able to research into `fbset` support? 720p on the 1366x768 atrix lapdock really tires the eyes fast |
| 20:07.00 | techn | mnemoc: it's bit tricky.. but works somehow.. |
| 20:07.43 | techn | use that http://forum.doozan.com/read.php?6,9002 tool |
| 20:07.58 | techn | and then change resolution to same with fbset |
| 20:08.00 | techn | :) |
| 20:09.12 | techn | but for full support we need edid support.. and I havent progressed with it yet |
| 20:10.09 | techn | I'm currently trying to get this a13 tablet working.. and then I can start removing ifdefs from disp |
| 20:12.35 | *** join/#arm-netbook ibrah (~chatzilla@212.49.88.104) |
| 20:14.16 | RaYmAn | anyone here happen to have an ASUS TF300, by pure chance? :P |
| 20:14.29 | mnemoc | you |
| 20:14.34 | RaYmAn | no |
| 20:14.46 | RaYmAn | I only have TF101 and TF201 |
| 20:14.52 | RaYmAn | not TF300 or TF700 |
| 20:15.12 | RaYmAn | is in dire need of a tester ;P |
| 20:15.32 | mnemoc | techn: but that method doesn't let you choose "not-standard" hdmi res :< |
| 20:18.50 | techn | mnemoc: edid would give timings for non stantard resolutions :/ |
| 20:19.24 | *** join/#arm-netbook mikey_w (~mike@c-71-63-115-202.hsd1.va.comcast.net) |
| 20:19.26 | mnemoc | techn: and does hardware actually support this? |
| 20:19.28 | techn | + way to get rid of hard codings |
| 20:19.42 | mnemoc | I mean A10/A13 based devices |
| 20:19.44 | *** join/#arm-netbook n6pfk (~mike@c-71-63-115-202.hsd1.va.comcast.net) |
| 20:20.07 | RaYmAn | EDID is just an I2C connection over HDMI, so should be easy to figure out if it's supported? |
| 20:20.17 | RaYmAn | :) |
| 20:20.38 | mnemoc | I2C over HDMI.... ufff |
| 20:20.54 | RaYmAn | it does it's job :) |
| 20:21.04 | mnemoc | :) |
| 20:22.10 | techn | https://github.com/amery/linux-allwinner/blob/allwinner-v3.0-android-v2/drivers/video/sunxi/hdmi/aw/hdmi_edid.c#L116 |
| 20:22.23 | techn | there is edid read in serial form |
| 20:23.10 | techn | RaYmAn: it could be i2c, but could not be ;) |
| 20:23.18 | techn | somekind hack it seems |
| 20:23.25 | RaYmAn | hm |
| 20:23.38 | RaYmAn | I can't rule out it's just tegra that exposes it as I2C. |
| 20:24.07 | RaYmAn | "The channel for transmitting the EDID from the display to the graphics card is usually the I²C bus, defined in DDC2B (DDC1 used a different serial format which never gained popularity)." |
| 20:25.27 | techn | could we create wrapper for that, so it looks like i2c for kernel? or should we use "firmware-edid", which I havent havent had time to study |
| 20:26.20 | RaYmAn | it's pretty damn hard to figure out what it does based on that code :/ |
| 20:26.21 | RaYmAn | lol |
| 20:26.52 | RaYmAn | HDMI_WUINT32( 0x540,(0<<12) + (3<<8));//enable analog sda/scl pad |
| 20:26.54 | *** join/#arm-netbook cat1 (~cat_x301@a91-152-66-200.elisa-laajakaista.fi) |
| 20:27.01 | RaYmAn | sda/scl sounds like i2c |
| 20:27.17 | techn | yep.. but why it won't show on i2c bus? |
| 20:27.39 | techn | or should it have driver to be shown there?' (i2c-detect) |
| 20:27.41 | RaYmAn | presumably they aren't exposing it as an i2c bus |
| 20:27.51 | RaYmAn | it needs a driver that exposes it, yes |
| 20:28.03 | techn | ah.. ok |
| 20:28.44 | RaYmAn | I guess it's unlikely the docs includea nything on this |
| 20:29.05 | *** join/#arm-netbook vgrade2 (~martinbro@cpc2-nrte22-2-0-cust128.8-4.cable.virginmedia.com) |
| 20:33.02 | RaYmAn | techn: looking at the i2c-sunxi.c driver, I'd say it looks like it's HDMI, just at a different (HDMI-specific) base register address |
| 20:33.10 | hno | The EDID line is wired on Mele HDMI port at least. And there is plenty of EDID references in the driver. |
| 20:36.12 | hno | drivers/video/sunxi/hdmi/aw/hdmi_edid.c is the driver. Plenty of hardcoded constants accessing unknown registers. |
| 20:36.23 | hno | all by numeric offset.. |
| 20:36.30 | RaYmAn | yes, techn just posted a link to that :) |
| 20:36.54 | RaYmAn | The register accesses seem to (at first glance) correspond with how the sunxi-i2c driver does I2C communication. |
| 20:37.35 | techn | RaYmAn: so is it different master? |
| 20:37.43 | hno | it is possible it's actually accessing an i2c controller. Need to check the register offset. |
| 20:38.02 | RaYmAn | techn: that's my theory anyhow :P |
| 20:38.19 | techn | hno: offset is hdmi's |
| 20:38.33 | hno | right, it is. |
| 20:39.06 | hno | a hdmi controller register. |
| 20:39.46 | hno | wonder which pin it goes to. |
| 20:41.28 | RaYmAn | wth is firmware-edid? |
| 20:41.35 | RaYmAn | pokes techn |
| 20:41.53 | RaYmAn | I suspect it's mostly an x86 thing? |
| 20:42.08 | hno | where did you find it? |
| 20:43.23 | techn | This enables access to the EDID transferred from the firmware. On the i386, this is from the Video BIOS. Enable this if DDC/I2C transfers do not work for your driver and if you are using nvidiafb, i810fb or savagefb. |
| 20:43.28 | techn | http://cateee.net/lkddb/web-lkddb/FIRMWARE_EDID.html |
| 20:45.45 | hno | found the pins in cubieboard shematics. R22(SDA) & R23(SCL), with theother HDMI control signals on P22(HPD), P23(CEC) |
| 20:47.27 | hno | hardwired pins with only these functions. |
| 20:47.51 | hno | which is why I didn't notice before. Mostly focusing on PIO pins. |
| 20:49.05 | RaYmAn | sounds odd itøs connected to CEC |
| 20:49.32 | techn | RaYmAn: thinking same |
| 20:49.59 | RaYmAn | I thought CEC was a seperate bus |
| 20:51.07 | hno | RaYmAn, it's a separate pin. What's odd? |
| 20:51.24 | RaYmAn | oh |
| 20:51.25 | RaYmAn | I misread |
| 20:51.27 | mnemoc | hno: beside enabling CONFIG_SUNXI_WDT, what should one do to not get rebooted? |
| 20:51.38 | RaYmAn | I thought you said CEC was connected to SCL and HPD to SDA |
| 20:51.51 | RaYmAn | hno: but you meant all four signals were there? |
| 20:52.01 | hno | RaYmAn, almost, less than a mm between ;) |
| 20:52.10 | RaYmAn | lol |
| 20:52.30 | hno | R22,R23,P22,P23 R != P |
| 20:52.49 | RaYmAn | yeah, I read that, I guess I just misunderstood :P |
| 20:53.30 | techn | hno: so it's different i2c master? |
| 20:53.40 | hno | mnemoc, the watchdog is disabled by default in sunxi since some time back. |
| 20:54.03 | hno | techn, it's not a documented TWI controller. |
| 20:54.18 | hno | but possible it is a TWI controller. |
| 20:54.24 | mnemoc | the LCD pins of the cubieboard also use 4 of those |
| 20:54.49 | mnemoc | by the name X1,X2,Y1,Y2 o.o |
| 20:54.49 | RaYmAn | hm - that'd make a neat testing ground then |
| 20:55.01 | RaYmAn | Connect something else to those pins and try and get it working :D |
| 20:55.24 | RaYmAn | or hekc - just an EEPROM at address 0x50 given that's what's on the DDC bus in most screens |
| 20:56.50 | hno | mnemoc, X1/X2/Y1/Y2 is touch panel. |
| 20:57.02 | hno | EDID is the SDA/SCL pins. |
| 20:57.27 | *** join/#arm-netbook rvalles (~rvalles@unaffiliated/rvalles) |
| 20:57.33 | hno | no HPD or CEC pins in the LCD connector. But does not make sense there. |
| 20:58.10 | hno | you usually do not hot plug a LCD panel, or receive IR codes from one. |
| 20:58.15 | mnemoc | :) |
| 20:59.18 | hno | Cubieboard also have pins for SPI0 which allows connecting a capacitive touch panel connector. |
| 20:59.20 | mnemoc | enabling debugging in sunxi-disp was a bad idea |
| 20:59.27 | RaYmAn | it would be cool to get CEC |
| 20:59.27 | hno | s/connector/controller/ |
| 20:59.46 | RaYmAn | it's working quite well on rpi |
| 21:00.27 | *** join/#arm-netbook eflatun (~eflatun@95.173.234.51) |
| 21:01.36 | techn | eflatun: ping |
| 21:11.33 | *** join/#arm-netbook madmalkav (~Hamlet@188.86.253.69) |
| 21:23.26 | hno | RaYmAn, unfortunately the CEC controller details is kept secret. |
| 21:23.40 | RaYmAn | yeah :( |
| 21:23.42 | RaYmAn | It's a pity |
| 21:24.05 | hno | no driver, and not in register data sheet from what I can see. |
| 21:24.32 | hno | well, none of HDMI is in the register data sheet. |
| 21:25.15 | RaYmAn | nvidia recently added a cec driver to tegra3 kernel source |
| 21:25.30 | RaYmAn | given how simple that is, you'd think it wouldn't be a secret :P |
| 21:27.20 | hno | Could try asking about it. |
| 21:28.15 | hno | but a bit far for me to implement it as I don't even have an HDMI to play with, even less one which talks CEC. |
| 21:28.29 | RaYmAn | yeah - but any docs could help, heh |
| 21:28.41 | RaYmAn | the major part of CEC is usually implemented in userspace |
| 21:30.19 | *** join/#arm-netbook mysteryname (~mysteryna@14-202-9-167.tpgi.com.au) |
| 21:32.09 | hno | Oh, we have full register list and bit names for HDMI audio controller. |
| 21:32.26 | hno | sun4i-hdmiaudio.h |
| 21:32.42 | hno | that's also missing from the register guide. |
| 21:33.01 | hno | I think.. |
| 21:33.10 | lundman | great |
| 21:35.33 | merbzt | hno: where is the register guide ? |
| 21:36.23 | hno | merbzt, not public. |
| 21:36.58 | merbzt | are the CedarX vpu registers defined there ? |
| 21:37.19 | hno | hm.. confusing. Those registers are documented as Digital Audio, with no word about HDMI. |
| 21:37.21 | hno | merbzt, no. |
| 21:38.51 | mnemoc | G2D is named "Mixer Processor" (or something like that) there |
| 21:40.33 | merbzt | http://rhombus-tech.net/allwinner_a10/A10_register_guide/ |
| 21:40.51 | merbzt | is the VPU listed there ? |
| 21:41.15 | hno | no, only it's base register. |
| 21:41.57 | merbzt | and that is ? |
| 21:42.55 | mnemoc | merbzt: it's composed by hno based on what's in the kernel and uboot sources |
| 21:43.46 | merbzt | sure, but what is the address or name in that list |
| 21:44.00 | mnemoc | and in the case of the VPU that info is close to nothing |
| 21:44.49 | merbzt | I know, I wanted to add what I found |
| 21:45.12 | merbzt | just need to know where to add it |
| 21:45.15 | hno | VE |
| 21:45.20 | merbzt | thnx |
| 21:45.31 | mnemoc | 0X01C0E000 |
| 21:45.36 | mnemoc | he was faster :< |
| 21:48.08 | mnemoc | good night |
| 22:09.26 | hno | merbzt, did it work adding a page for you? |
| 22:29.13 | traeak | http://venturebeat.com/2012/09/15/hardware-is-dead/ |
| 22:32.03 | merbzt | hno: yes, I got distracted, I'll add the info I found now |
| 22:42.27 | ZaEarl | link bait |
| 22:55.01 | steev | ZaEarl: truth |
| 23:46.42 | hno | merbzt, are these from symbol names? There is also mp4 and mpeg2 of similar _regNN names |
| 23:48.45 | hno | h264, jpeg, mp4, mpeg2, rv, vc1, vp8 |
| 23:49.00 | hno | confusing. I would expect a firmware somewhere. |