| 00:10.19 | *** join/#arm-netbook traeak (~bolsen@75-151-91-165-Colorado.hfc.comcastbusiness.net) |
| 00:15.39 | hramrach | ssvb: libMali has parts of libDRI2 compiled in |
| 00:16.02 | hramrach | especially the DRI2GetBuffers which it uses wrongly |
| 00:16.53 | hramrach | so would require editing the object to replace the funcion /o\ |
| 00:17.40 | hramrach | it seems standard practice to compile a private copy of libdri into stuff |
| 00:49.41 | L84Supper | http://www.ubuntu.com/ new ARM tablet being announced in 15 hours? |
| 00:50.43 | L84Supper | http://www.paritynews.com/hardware/tablets/item/660-canonical-announcing-ubuntu-tablet-tomorrow |
| 00:52.05 | L84Supper | isn't Ubuntu still pretty close to Linux? :) |
| 00:55.21 | *** join/#arm-netbook Avernos (~avernos@114.245.255.37) |
| 00:55.21 | *** join/#arm-netbook Avernos (~avernos@unaffiliated/avernos) |
| 00:59.25 | *** join/#arm-netbook Avernos (~avernos@222.128.188.169) |
| 00:59.25 | *** join/#arm-netbook Avernos (~avernos@unaffiliated/avernos) |
| 01:03.56 | *** join/#arm-netbook Avernos_ (~avernos@114.245.250.7) |
| 01:13.04 | *** join/#arm-netbook stefanro1 (~stefan@p57B94C4C.dip.t-dialin.net) |
| 01:24.50 | *** join/#arm-netbook L84Supper (~Larch@unaffiliated/l84supper) |
| 01:31.08 | hramrach | ssvb: anyway, if it was abuse of DRI2GetBuffers this hack should fix it but it does not for me: http://hpaste.org/82659 |
| 01:31.47 | hramrach | this is the place where the buffers get deallocated |
| 01:32.34 | hramrach | DRI2GetBuffers has not format information so sets format to 0 which does not match any actual format |
| 01:34.17 | hramrach | this would also mean that the description in that email is incorrect becasuse ony attachments requested get allocated/re-allocated |
| 01:36.21 | ssvb | hramrach: yes, the format field is simply not used |
| 01:36.50 | ssvb | what exactly is incorrect? |
| 01:40.05 | *** join/#arm-netbook Avernos (~avernos@222.128.135.6) |
| 01:40.05 | *** join/#arm-netbook Avernos (~avernos@unaffiliated/avernos) |
| 01:40.08 | ssvb | DRI2GetBuffers seems to be rather loosely defined, it has fields as "name" (actually gets used to store the secure id) and "flags" (actually gets used to store the offset in UMP buffer) |
| 01:41.18 | ssvb | how to interpret these fields is left to the DDX and the actual client application (mali blob) |
| 01:42.54 | hramrach | yeah, the format is passed verbatim to MaliDRI2CreateBuffer which just saves it so the actual buffer info will have 0 there |
| 01:43.24 | hramrach | so where is the logic that destroys the buffer on MaliDRI2CreateBuffer? |
| 01:44.00 | hramrach | when the buffer was allocated with DRI2GetBuffers rhather than DRI2GetBuffersWithFormat? |
| 01:44.38 | ssvb | that's a good question, I did not look that deep into the x server sources |
| 01:44.49 | hramrach | because the two do exactle the same thing except DRI2GetBuffers fills format with 0 |
| 01:48.33 | hramrach | it would have to be in MaliDRI2DestroyBuffer presumably |
| 01:50.44 | *** join/#arm-netbook Avernos_ (~avernos@221.223.234.62) |
| 01:51.24 | ssvb | hramrach: seems to be here - http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/dri2/dri2.c?id=xorg-server-1.13.2#n665 |
| 01:54.29 | ssvb | or maybe not |
| 01:57.04 | ssvb | more like here - http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/dri2/dri2.c?id=xorg-server-1.13.2#n511 |
| 01:57.42 | ssvb | this code destroys the existing buffers and replaces them with the newly created ones |
| 01:59.04 | ssvb | hramrach: however even if you hack the x server to tweak this behaviour, some support code for correctly swapping buffers is still needed in the DDX |
| 01:59.19 | hramrach | but regardless of WithFormat |
| 02:00.27 | hramrach | yes, that part destroys the buffers but it does so on any GetBuffers* call afaict |
| 02:01.08 | hramrach | the ddx is out of that |
| 02:01.42 | ssvb | that part should somehow call ddx to do the real buffers destruction job |
| 02:02.14 | hramrach | It does |
| 02:06.28 | ssvb | in any case, I think that we have to add some hack to ddx in order to override the things done in "hw/xfree86/dri2/dri2.c" and manage the buffers the way how it is expected by the mali blob |
| 02:06.42 | hramrach | it calls MaliDRI2DestroyBuffer |
| 02:07.28 | hramrach | and how it is described in that mail with new protocol description |
| 02:07.37 | hramrach | or what does it say, exactly? |
| 02:07.49 | hramrach | that you can request buffers |
| 02:08.09 | hramrach | but not what will happen to buffers you have already requested |
| 02:09.08 | ssvb | that mail was a proposal for this new function, maybe it was changed before this code got committed |
| 02:09.33 | ssvb | it looks like DRI2GetBuffersWithFormat is not going to help us in any way |
| 02:09.41 | hramrach | it does not really say anything one way or the other, either |
| 02:09.51 | hramrach | there is just no description of these functions |
| 02:10.22 | hramrach | they just do someting DRI specific which is tightly coupled with the Xfree DDX drivers |
| 02:11.01 | ssvb | or actually it's the buffers reusing logic |
| 02:11.28 | ssvb | we may try to trick it to use the old buffer in the right way |
| 02:12.31 | hramrach | you could just return the old buffers |
| 02:12.48 | hramrach | which the function presumably does if hte format matches |
| 02:13.14 | hramrach | so it probably thinks it does not for some reason |
| 02:14.44 | ssvb | we want DRI2BufferFrontLeft to be reused, and the DRI2 code has an explicit check to make sure that it gets reallocated |
| 02:18.14 | *** join/#arm-netbook cnxsoft (~cnxsoft@118.172.57.65) |
| 02:19.34 | hramrach | it has an explicit check to make sure one is present |
| 02:19.56 | hramrach | but if there is any logic it should either |
| 02:21.02 | ssvb | hramrach: http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/dri2/dri2.c?id=xorg-server-1.13.2#n493 |
| 02:21.45 | ssvb | if "attachment == DRI2BufferFrontLeft" then it calls create_buffer instead of reusing the old one |
| 02:22.22 | hramrach | oh, indeed |
| 02:22.41 | hramrach | it tosses the front buffer every time you request any buffer |
| 02:22.49 | hramrach | sounds awesome |
| 02:23.08 | hramrach | while(1) GetBuffers .. |
| 02:26.42 | ssvb | we can try to add a hack to reuse the old DRI2BufferFrontLeft buffer from MaliDRI2CreateBuffer :) |
| 02:27.56 | ssvb | so if we are requested to create DRI2BufferFrontLeft, just check the list of existing attachments for the drawable, find the old DRI2BufferFrontLeft buffer and return it |
| 02:29.06 | ssvb | this might work |
| 02:30.09 | hramrach | I tried removing the frontleft check in X server |
| 02:30.16 | hramrach | does not seem to help |
| 02:30.45 | ssvb | does not help to what? |
| 02:30.59 | hramrach | flashing in gnome-shell |
| 02:31.29 | ssvb | that's because the ddx is missing the correct buffers swap logic |
| 02:31.51 | ssvb | it currently just provides the same buffer for both front and back |
| 02:32.04 | hramrach | ah |
| 02:35.16 | ssvb | I'll try to add the needed changes to DDX, and also the hack to prevent DRI2BufferFrontLeft reallocation so that x server patching is not necessary |
| 02:35.32 | ssvb | but tomorrow, now I need to go to bed |
| 02:36.31 | hramrach | good night :) |
| 02:37.17 | ssvb | :) |
| 02:38.14 | *** join/#arm-netbook Avernos (~avernos@222.128.188.80) |
| 02:38.14 | *** join/#arm-netbook Avernos (~avernos@unaffiliated/avernos) |
| 03:05.23 | *** join/#arm-netbook Avernos (~avernos@222.128.188.80) |
| 03:05.23 | *** join/#arm-netbook Avernos (~avernos@unaffiliated/avernos) |
| 03:07.49 | *** join/#arm-netbook stefanro (~stefan@p57B94C4C.dip.t-dialin.net) |
| 04:03.52 | *** join/#arm-netbook ZaEarl (~malmrose@c-67-166-109-0.hsd1.ut.comcast.net) |
| 04:24.03 | *** join/#arm-netbook aholler (~aholler@p57B203BC.dip0.t-ipconnect.de) |
| 04:25.54 | *** join/#arm-netbook Avernos (~avernos@222.128.188.80) |
| 04:25.54 | *** join/#arm-netbook Avernos (~avernos@unaffiliated/avernos) |
| 04:28.41 | *** join/#arm-netbook KoH_ (~kane@trir-5d8054ec.pool.mediaWays.net) |
| 04:40.00 | *** join/#arm-netbook mnemoc (~amery@geeks.cl) |
| 05:07.43 | ZaEarl | finally a tablet-friendly Ubuntu build? http://www.ubuntu.com/ |
| 05:10.37 | rm | "finally"? |
| 05:11.15 | rm | it's something that we were waiting for eagerly, hoping every day it comes out asap? :) |
| 05:17.16 | *** join/#arm-netbook NAiL (~repvik@puck.tjene.re) |
| 05:17.21 | *** join/#arm-netbook j^ (~j@2002:4e2e:4fd0::9) |
| 05:17.31 | *** join/#arm-netbook Thomas42 (~Thomas42@5.9.236.105) |
| 05:18.12 | *** join/#arm-netbook vgrade (~root@static.43.45.47.78.clients.your-server.de) |
| 05:18.14 | *** join/#arm-netbook slapin (~slapin@slapinbuild.ihdev.net) |
| 05:18.28 | *** join/#arm-netbook uwe_mobile (~uwe@static.88-198-8-117.clients.your-server.de) |
| 05:19.59 | *** join/#arm-netbook RaYmAn (rayman@rayman.dk) |
| 05:32.19 | *** part/#arm-netbook Ershov (~Thunderbi@89.163.11.110) |
| 05:51.17 | *** join/#arm-netbook abesis (~abesis@217.131.210.89) |
| 06:31.45 | *** join/#arm-netbook steev (uid1383@gentoo/developer/steev) |
| 06:43.51 | *** join/#arm-netbook roxfan (dunno@122.221-200-80.adsl-dyn.isp.belgacom.be) |
| 06:47.19 | *** join/#arm-netbook abesis (~abesis@78.187.167.191) |
| 07:07.10 | *** join/#arm-netbook Holo_ (uid6962@gateway/web/irccloud.com/x-hkvnjqwtvxdgjadc) |
| 07:07.15 | *** join/#arm-netbook niftylettuce (uid2733@gateway/web/irccloud.com/x-rihphcvbrzqrfjhe) |
| 07:13.37 | *** join/#arm-netbook abesis2 (~abesis@78.187.167.191) |
| 07:15.31 | *** join/#arm-netbook anunnaki (~anunnaki@174.54.115.236) |
| 07:35.55 | *** join/#arm-netbook pcat (~cat@37-219-42-37.nat.bb.dnainternet.fi) |
| 07:42.19 | *** join/#arm-netbook gzamboni (~gzamboni@235.152.200.77.rev.sfr.net) |
| 07:44.41 | *** join/#arm-netbook rellla (~rellla@p5B078559.dip0.t-ipconnect.de) |
| 08:26.44 | *** join/#arm-netbook Ershov (~Thunderbi@89.163.11.110) |
| 08:26.47 | *** part/#arm-netbook Ershov (~Thunderbi@89.163.11.110) |
| 08:52.10 | *** join/#arm-netbook rellla2 (~rellla@p5B0783BF.dip0.t-ipconnect.de) |
| 09:13.12 | *** join/#arm-netbook abesis (~abesis@78.187.167.191) |
| 09:25.24 | *** join/#arm-netbook aesok (~quassel@84.23.55.38) |
| 09:32.04 | *** join/#arm-netbook abesis2 (~abesis@78.187.167.191) |
| 09:55.25 | *** join/#arm-netbook popolon (~popolon@82.225.234.108) |
| 10:08.22 | *** join/#arm-netbook pcat (~cat@37-219-42-37.nat.bb.dnainternet.fi) |
| 10:21.28 | *** join/#arm-netbook sspiff (c24e0469@gateway/web/freenode/ip.194.78.4.105) |
| 11:29.53 | *** join/#arm-netbook soooga (~soooga@175.155.20.165) |
| 11:49.28 | *** join/#arm-netbook Quarx (~Quarx@94.137.43.212) |
| 11:54.55 | *** join/#arm-netbook rz2k (~rz2k@95-25-199-38.broadband.corbina.ru) |
| 11:56.21 | *** join/#arm-netbook ganbold_ (~Ganbold@202.21.108.193) |
| 11:57.25 | *** join/#arm-netbook hipboi (~hipboi@27.23.179.182) |
| 12:00.35 | *** join/#arm-netbook cnxsoft (~cnxsoft@118.172.173.70) |
| 12:03.36 | *** join/#arm-netbook Gumboot (~sh1@82.69.188.246) |
| 12:58.17 | hramrach | rm: you have any linux distro that works on tablets? |
| 13:00.16 | Turl | hramrach: check out the pengpod :p |
| 13:00.26 | *** join/#arm-netbook Avernos (~avernos@222.128.188.80) |
| 13:00.26 | *** join/#arm-netbook Avernos (~avernos@unaffiliated/avernos) |
| 13:01.48 | rm | no |
| 13:11.06 | *** join/#arm-netbook aesok (~aesok@128-72-132-189.broadband.corbina.ru) |
| 13:11.17 | hramrach | well, then ubuntu for tablet is something we have been waiting for ;-) |
| 13:18.53 | hramrach | Turl: where is the pengophod distro which is so tablet friendly? |
| 13:21.11 | Turl | hramrach: http://www.youtube.com/watch?feature=player_embedded&v=RKyK2uop-Vo |
| 13:28.51 | *** join/#arm-netbook roxfan (dunno@122.221-200-80.adsl-dyn.isp.belgacom.be) |
| 13:28.52 | Turl | drachensun: your security bulletin's instructions look wrong to me |
| 13:30.23 | Turl | drachensun: it should be openssh-server, not ssh |
| 13:30.32 | hramrach | Turl: ENOFLASH |
| 13:30.46 | Turl | hramrach: ? |
| 13:31.20 | mnemoc | youtube does html5 video too |
| 13:32.05 | hramrach | and defaults to flash |
| 13:32.22 | Turl | my flash is disabled yet I saw that video |
| 13:32.45 | mnemoc | hramrach: check http://www.youtube.com/html5 ... you might need to enable something |
| 13:34.20 | hramrach | well, iceweasel does not seem to do h264 |
| 13:34.46 | Turl | it's on webm |
| 13:34.46 | hramrach | and YT refuses to serve the videos in WebM or whatever |
| 13:34.52 | Turl | I'm using iceweasel too |
| 13:36.24 | hramrach | This video is currently unavailable |
| 13:36.46 | Turl | youtube must hate you or something |
| 13:37.13 | Turl | anyway, it's just a linaro image working on a tablet |
| 13:38.26 | hramrach | Obviously. |
| 13:38.45 | hramrach | They can't give you plain link to a video you can download and play in whatever you want |
| 13:39.18 | hramrach | they must fuss about doing flash by default and broken html5 when you force them to switch |
| 13:42.39 | Turl | well, their html5 video works for me on iceweasel 18 |
| 13:44.23 | hramrach | that I have too |
| 13:45.08 | hramrach | but it seems it's trying to do flash even when the html5 page says I 'on html5 trial' |
| 13:45.08 | *** join/#arm-netbook Avernos (~avernos@222.128.188.80) |
| 13:45.08 | *** join/#arm-netbook Avernos (~avernos@unaffiliated/avernos) |
| 13:45.19 | hramrach | thanks for the links |
| 13:45.26 | hramrach | but they don't work :s |
| 13:46.28 | Turl | it even did html5 for me with the trial disabled and no flash |
| 13:52.59 | *** join/#arm-netbook herdingcat (~huli@222.128.173.109) |
| 14:14.55 | drachensun | turl: Thanks, yup that is the package to remove |
| 14:19.37 | *** join/#arm-netbook Turl (~Turl@cyanogenmod/maintainer/Turl) |
| 14:34.38 | *** join/#arm-netbook Turl (~Turl@cyanogenmod/maintainer/Turl) |
| 14:46.41 | *** join/#arm-netbook wingrime (~wingrime@78.109.115.103) |
| 14:48.29 | *** join/#arm-netbook abesis (~abesis@78.187.167.191) |
| 15:13.18 | *** part/#arm-netbook cnxsoft (~cnxsoft@118.172.173.70) |
| 15:22.07 | *** join/#arm-netbook herdingcat (~huli@114.249.215.159) |
| 16:11.44 | SPG | 03Luis 05master f88c4fb 06rhombus 03allwinner_a10/orders/lscalder.html * 14http://git.hands.com/?p=rhombus.git;a=commitdiff;h=f88c4fb |
| 16:13.21 | SPG | 03Luis 05master a7305fe 06rhombus 10allwinner_a10/orders/lscalder.html * 14http://git.hands.com/?p=rhombus.git;a=commitdiff;h=a7305fe |
| 16:13.56 | *** join/#arm-netbook tinti (~tinti@pdpc/supporter/student/tinti) |
| 16:14.42 | *** join/#arm-netbook ZaEarl (~malmrose@c-67-166-109-0.hsd1.ut.comcast.net) |
| 16:17.07 | *** join/#arm-netbook Turl (~Turl@cyanogenmod/maintainer/Turl) |
| 16:20.51 | SPG | 03Luis 05master bf499dd 06rhombus 03allwinner_a10/orders/lscalder/discussion.mdwn * 14http://git.hands.com/?p=rhombus.git;a=commitdiff;h=bf499dd |
| 16:50.04 | *** join/#arm-netbook eFfeM (~frans@c73189.upc-c.chello.nl) |
| 16:52.25 | *** join/#arm-netbook hp__ (~kvirc@d5153E228.access.telenet.be) |
| 16:56.37 | *** join/#arm-netbook Turl (~Turl@cyanogenmod/maintainer/Turl) |
| 17:04.54 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 17:06.20 | *** join/#arm-netbook pcat (~cat@188.238.27.232) |
| 17:18.19 | L84Supper | anyone here know of a decent (well supported, user friendly) GPL tablet based POS system? |
| 17:39.03 | *** join/#arm-netbook Eigen (~Eigen@S0106001310f0b056.vn.shawcable.net) |
| 17:40.47 | *** join/#arm-netbook voronaam (~avorona@159.153.138.99) |
| 17:56.12 | Turl | ZaEarl: http://www.youtube.com/watch?v=h384z7Ph0gU&feature=player_embedded |
| 17:57.00 | *** join/#arm-netbook L84Supper (~Larch@unaffiliated/l84supper) |
| 18:01.09 | traeak | http://www.youtube.com/watch?v=h384z7Ph0gU |
| 18:01.12 | traeak | cut the embed part :-p |
| 18:09.43 | ZaEarl | looks good |
| 18:10.26 | ZaEarl | my big question, is it running on a Linux kernel with x11, or Android kernel with android graphics drivers? |
| 18:18.52 | libv | supposedly on tegra and exynos5... i really doubt that spaceshuttle got the binaries drivers for that, and got them fully integrated |
| 18:18.59 | libv | so i think it will run on top of android |
| 18:19.05 | libv | or it will run like a dog |
| 18:20.30 | ZaEarl | they've implied that if android is already running on the device, that ubuntu wouldn't be hard, so I suspect android kernel too |
| 18:21.45 | L84Supper | so this was what the countdown was all about? http://www.ubuntu.com/ |
| 18:35.33 | *** join/#arm-netbook aholler (~aholler@p57B203BC.dip0.t-ipconnect.de) |
| 18:47.36 | jelly-home | libv: an ubuntu dev tells me the thing runs an ubuntu kernel, not the android one |
| 18:48.23 | jelly-home | well, he also says the whole thing is open source and I specifically noted the hw is tegra 3 |
| 18:48.54 | jelly-home | and that providing source for drivers would be a very significant move for nvidia |
| 18:49.25 | jelly-home | we'll see |
| 18:50.37 | traeak | ouya hardware |
| 18:54.35 | libv | jelly-home: open source drivers will not happen on their own, nvidia will not do that out of the blue |
| 18:55.02 | libv | jelly-home: the question is, are there proper gnu/linux tegra3 drivers or not |
| 18:55.31 | *** join/#arm-netbook bfree (~niall@109.255.245.157) |
| 18:56.11 | libv | i would really be amazed if there were proper gles drivers for gnu/linux falling out of ubuntu |
| 18:56.43 | libv | i still have to see solid gnu/linux mali binaries for the snowball and the origen |
| 18:56.55 | libv | i have not managed to find any for the exynos based origen for instance |
| 18:57.02 | jelly-home | well -- I trust him about the kernel part, and will wait to see what comes on top of that |
| 18:58.00 | libv | i think that they might be running the chromebook exynos5 gles drivers |
| 18:58.05 | libv | for the nexus10 |
| 18:58.46 | jelly-home | 10" is exynos5? |
| 18:59.02 | jelly-home | only looked at nexus 7 specs |
| 18:59.05 | mnemoc | yes |
| 18:59.17 | mnemoc | like the chromebook, but with better display :| |
| 19:00.18 | jelly-home | Re: displays. HTC's new phone has effin 469dpi |
| 19:00.27 | jelly-home | 468* but... what |
| 19:01.20 | mnemoc | and laptops are stuck at 1366x768, and LCDs at 1920x1080 :< |
| 19:02.49 | jelly-home | ok, they're starting to put 1920 in 13" ultrabooks as well |
| 19:03.41 | traeak | that's brutal at that resolution |
| 19:03.44 | mnemoc | N133HSE-EA1 is 13.3" and 1080p for ~400 yuan on taobao |
| 19:03.47 | traeak | i guess tons of upscaling |
| 19:04.05 | traeak | or whatever it is (big fonts) |
| 19:04.22 | mnemoc | N116HSE-EA1 is 11.6" and 1080p for mostly the same price |
| 19:04.42 | mnemoc | and why the *censored* they keep using 1366x768?! |
| 19:04.49 | jelly-home | it's cheeeeep |
| 19:05.45 | mnemoc | those panels above cost less than $70 |
| 19:05.48 | jelly-home | I'm staying away from laptops ever since they all got 16:9 screens; 16:10 was barely passable |
| 19:06.19 | traeak | why not passable? |
| 19:06.47 | jelly-home | too little vertical space, or too small pixels for my myopic eyes |
| 19:07.23 | traeak | for my tastes it's wide enough for 2 side by side xterms |
| 19:08.55 | jelly-home | not wide enough was never the issue for me; 1024x768 was wide enough for a 132x48 term |
| 19:10.47 | traeak | 80 columns wide :-p |
| 19:10.57 | traeak | you're wasting 52 columns |
| 19:10.57 | traeak | hehe |
| 19:20.02 | libv | how hard would it be to have unity talk to surfaceflinger? |
| 19:25.31 | libv | "Ubuntu has already been adapted to run on chipsets using the ARM and Intel x86 architectures relevant for mobile devices, with the core system based around a typical Android Board Support Package (BSP)." |
| 19:26.08 | libv | so android underneath, no proper gnu/linux drivers, still bionic and its insane loader |
| 19:27.22 | mnemoc | chroot saves you from bionic |
| 19:27.36 | libv | but that does not get you working drivers |
| 19:27.44 | mnemoc | :< |
| 19:28.17 | libv | and i really really doubt that they forgo hw accel |
| 19:28.23 | libv | not on this hw, not in this market |
| 19:28.59 | libv | so i really do think that they have bolted themselves on top of surfaceflinger |
| 19:30.07 | libv | "android board support package", that, to me, translates to "EGL is whatever android does", so surfaceflinger |
| 19:30.07 | *** join/#arm-netbook abesis (~abesis@217.131.210.89) |
| 19:31.47 | jelly-home | eh |
| 19:33.13 | jelly-home | but that's ubuntu phone. Maybe ubuntu tablet is completely different...! |
| 19:38.48 | *** join/#arm-netbook anunnaki (~anunnaki@c-174-54-115-236.hsd1.pa.comcast.net) |
| 19:44.38 | *** join/#arm-netbook j1nx_ (~IceChat9@188-142-102-64.FTTH.ispfabriek.nl) |
| 19:45.21 | j1nx_ | Hi there guys |
| 19:45.45 | j1nx_ | can we buy an EOMA card already? :D |
| 19:53.09 | mnemoc | j1nx_: no |
| 20:01.17 | w00tc0d3 | any CyanogenMod requests for a phone here? |
| 20:02.01 | jelly-home | w00tc0d3: what? |
| 20:02.20 | w00tc0d3 | jelly-home: if you have an Android phone, which needs CM. Tell me :) |
| 20:02.32 | jelly-home | oh! Thanks I guess |
| 20:02.34 | *** join/#arm-netbook abesis (~abesis@217.131.210.89) |
| 20:04.12 | j1nx_ | I just sended a question to the arm-netbook mailing list about CMDLINE_EXTEND |
| 20:04.30 | j1nx_ | Anybody in here who can help me out a bit? |
| 20:06.44 | Turl | didn't get any email from arm-netbook |
| 20:07.29 | j1nx_ | hmm |
| 20:07.59 | j1nx_ | Might still be bouncing around in virtual space |
| 20:11.03 | *** join/#arm-netbook eebrah (~chatzilla@212.49.88.109) |
| 20:13.47 | *** join/#arm-netbook abesis2 (~abesis@217.131.206.192) |
| 20:20.07 | *** join/#arm-netbook focus_it (~focus_it@cpc7-dals17-2-0-cust182.hari.cable.virginmedia.com) |
| 20:30.25 | libv | jelly-home: apparently ubuntu for tablets will need a dual A15 minimum |
| 20:30.39 | libv | jelly-home: and here i was thinking that the nexus7 had a quad a9 |
| 20:33.07 | Turl | libv: how can they 'require' a dual A15? |
| 20:34.02 | libv | beats me |
| 20:34.38 | libv | any a15s shipping apart from the exynos5? |
| 20:35.14 | Turl | OMAP 5 on Q2 2013 |
| 20:35.28 | Turl | 2.0 GHz Dual-core ARM Cortex-A15 + Two Cortex-M4 |
| 20:35.51 | libv | i worked with the early panda 5 over the summer |
| 20:36.11 | libv | customer was told it was a quadcore... *sigh* |
| 20:36.33 | mnemoc | do they sell omap4 openly yet? |
| 20:36.46 | libv | don't think so |
| 20:36.46 | Turl | it is, you just don't use the 4 cores simultaneously I guess |
| 20:36.57 | libv | Turl: the m4s are used for media stuff |
| 20:37.14 | Turl | libv: hm, not big.LITTLE? |
| 20:37.17 | anunnaki | sorry to jump in your convo. but is there a minimum for adding a touchscreen |
| 20:37.33 | libv | Turl: yup, no big.little |
| 20:37.42 | libv | and then ti decided to leave the mobile marked |
| 20:37.58 | Turl | libv: fwiw, T3 is a penta cortex A9 |
| 20:38.14 | Turl | it just has one crippled core at 500mhz |
| 20:38.27 | libv | but doesn't officially meet the ubuntu minimum specs |
| 20:38.31 | Turl | anunnaki: hm? |
| 20:38.35 | anunnaki | like would a small touchscreen work well on a rpi or is the processor not powerful enough |
| 20:38.45 | anunnaki | or does it not matter |
| 20:38.50 | Turl | anunnaki: depends on what touchscreen technology |
| 20:39.11 | Turl | usually they have a separate processor and you just read the (x, y) values on the device |
| 20:39.30 | Turl | libv: you need a Nexus 10 |
| 20:39.51 | Turl | and it has mali ;) |
| 20:40.09 | RaYmAn | Turl: it also has a ARM7TDMI core, so 6core? ;) |
| 20:40.29 | libv | Turl: i will order myself a chromebook in a few weeks |
| 20:40.45 | libv | just to get one before they run out |
| 20:40.51 | anunnaki | Turl, oh neat.. didnt know they have their own. a little lcd screen like beaglebone has would be cool but i rather touch capabilities |
| 20:40.51 | Turl | RaYmAn: and a powervr, and a BP if you choose the 3G one |
| 20:40.56 | libv | still have too much mali-400 stuff to do |
| 20:41.09 | RaYmAn | Turl: powervr? |
| 20:42.03 | Turl | RaYmAn: err sorry, was thinking of sth else |
| 20:42.05 | libv | which reminds me, i was cleaning up mali-libs |
| 20:42.09 | Turl | tegra has... tegra |
| 20:42.31 | RaYmAn | indeed |
| 20:42.59 | libv | mnemoc: what should i do with these changes, push them directly, or toss them in a branch first? |
| 20:43.57 | traeak | wierd, how does ubuntu enforce a15? special instructions that a9 doesn't have ? |
| 20:45.22 | mnemoc | libv: `make install` changes? maybe tag first and push after? |
| 20:45.32 | roxfan | cpuid check! |
| 20:46.02 | RaYmAn | traeak: given they only seem to give it to partners, they probably enforce it contractually :P |
| 20:46.28 | libv | ok, so just a tag will suffice for you? |
| 20:46.50 | libv | or should i push to a repo of my own to get people to have a look over it? |
| 20:47.26 | libv | traeak: they are demonstrating it on a tegra3 based nexus 7, so the a15 requirement is quite bogus |
| 20:48.29 | libv | techn_: please do not do merges for single commits with no complicated histor |
| 20:49.19 | libv | especially not for one which i do not find overly useful, and which probably would not have been a problem if there was an x11 test out in the public already, which there will be soon |
| 20:49.48 | mnemoc | libv: I'm happy with the tag |
| 20:49.55 | RaYmAn | I guess a15 might be requirement for their target performance levels |
| 20:50.19 | libv | ok |
| 20:50.43 | libv | mnemoc: what should the tag be to make sense in the sunxi ecosystem? |
| 20:51.12 | libv | mnemoc: also, how do you want me to handle the deprecation of the separate libump repo? |
| 20:52.23 | mnemoc | people loves date based tags/releases (like 2013.2) these days |
| 20:52.46 | libv | for whatever good those are :) |
| 20:52.49 | libv | ok |
| 20:52.52 | mnemoc | :p |
| 20:53.00 | mnemoc | git tag -a 1 ? |
| 20:53.47 | libv | actually, it makes sense to tag the commits i made back in november |
| 20:54.08 | mnemoc | fine with me |
| 20:54.12 | libv | the one commit up there, which i made last week, was really the snowball that started the current avalanche |
| 20:54.40 | mnemoc | regarding the libump deprecation... that might deserve a temporal branch and some mail expailing it |
| 20:55.23 | mnemoc | libump separated repo I mean |
| 20:55.51 | traeak | libv figured so. also means it shoudl run fine on a cortex a7 as well |
| 20:56.20 | mnemoc | i'm somehow not inclined to mix closed source with free software in the same repos. but as libump is also from arm and we need tighter integration to get the whole thing working... |
| 20:56.54 | libv | well, the only thing that made sense was to fold it into the mali-libs repo, so that the umpblobs vanish, and all can get installed coherently with little extra overhead and little chance of mess-up |
| 20:57.06 | libv | yeah, i know, this is the one thing that i find non-ideal here |
| 20:57.26 | libv | but the benefits far outweigh that awkwardness |
| 20:57.43 | libv | and the free code has nice headers |
| 20:58.07 | mnemoc | what about getting mali-libs as a submodule inside a rename of libump's repo? |
| 20:58.09 | libv | the status of the binaries is very unclear as well |
| 20:58.33 | libv | it'll have to be more than a rename. |
| 20:58.55 | libv | let me clean up my stuff, and push it out to a personal repo so you can see what happened |
| 20:59.04 | mnemoc | i mean rename to not lose the history |
| 20:59.46 | libv | there is little history |
| 20:59.57 | libv | there basically are 2 libump versions |
| 21:00.55 | mnemoc | so, what about a new sunxi-mali including the blobs as a submodule, building and installing the whole |
| 21:01.17 | mnemoc | would that carry much awkwardness? |
| 21:01.25 | libv | yeah, that indeed makes the most sense |
| 21:02.01 | libv | clone mali-libs into sunxi-mali, then throw out the binaries and add a submodule, then my upcoming changes |
| 21:02.31 | libv | we should've done this in november, but hindsight and such |
| 21:03.31 | mnemoc | if we start sunxi-mali from mali-libs history will include proprietary poison |
| 21:04.18 | libv | ok, will recycle my november commits as much as possible |
| 21:04.42 | libv | mnemoc: can i create that repo, or do you need to do so? |
| 21:04.53 | mnemoc | i believe you should be able to |
| 21:05.13 | libv | ok, seems like we have a plan then :) |
| 21:05.50 | mnemoc | yeah :) and as git lets you export commits as files recycling history shouldn't be hard |
| 21:06.34 | mnemoc | loves how easy is to commit VCS heresy with git :p |
| 21:06.42 | *** join/#arm-netbook abesis (~abesis@217.131.206.192) |
| 21:07.30 | mnemoc | sanctity of timeline is... bornig :p |
| 21:07.40 | mnemoc | boring* |
| 21:08.55 | libv | mnemoc: should we, while we are at it, rename mali-libs to sunxi-mali-proprietary, and deprecate mali-libs entirely as well? |
| 21:09.35 | libv | since we are messing everything up anyway |
| 21:10.37 | mnemoc | libv: fine with me |
| 21:11.14 | mnemoc | sunxi-bsp will need to be adjusted for the new sunxi-mali anyway |
| 21:11.31 | mnemoc | techn_: ---^ comments? |
| 21:11.36 | libv | ok, so creating two new repos, one with the libs and the bottom end of the build system which will not be useful on its own, and a README at the top end |
| 21:12.13 | libv | and the other with some cherry picks of the existing mali-libs, and the end result will be like what i currently have here locally, but with lib/mali/ a submodule |
| 21:12.27 | *** join/#arm-netbook merbzt (~benjamin@c-94-255-219-122.cust.bredband2.com) |
| 21:13.02 | *** join/#arm-netbook alcides (~alcides@unaffiliated/alcides) |
| 21:13.13 | mnemoc | libv: :) |
| 21:13.27 | libv | rz2k has been spreading some howtos for using our mali libs for the odroid, so he will have to go and update those as well |
| 21:14.05 | libv | i am not sure how the android guys are dealing with sunxi stuff atm |
| 21:14.29 | mnemoc | Turl: ---^ ? |
| 21:15.19 | libv | let me push my current tree out to a repo of my own, a repo that i will destroy once everything is in place |
| 21:16.10 | mnemoc | please don't delete the "old" mali-libs yet |
| 21:16.14 | libv | i will not |
| 21:16.20 | libv | i will also not remove those repos |
| 21:16.21 | mnemoc | great |
| 21:16.26 | rz2k | libv: odroid no longer uses our stuff |
| 21:16.31 | rz2k | they have automated installer |
| 21:16.36 | libv | ok |
| 21:17.44 | libv | mnemoc: by deprecating i mean would empty out the tree in a commit to master and put a README.deprecated in there pointing to the real repo |
| 21:18.01 | libv | s/would // |
| 21:19.21 | mnemoc | sounds good |
| 21:20.24 | libv | i am going to kill the github.com/libv/mali-libs repo i am about to create though :) |
| 21:20.50 | Turl | libv: we use proprietary repos with cool makefiles, any change to those repos won't affect us |
| 21:20.56 | Turl | https://github.com/allwinner-dev-team/proprietary_vendor_allwinner/tree/jellybean/zatab |
| 21:22.03 | libv | ah, ok |
| 21:22.29 | libv | is there any reason why we are keeping android binaries in our mali-libs then? |
| 21:22.50 | Turl | backup? :P |
| 21:23.38 | mnemoc | libv: because we wanted to be able to build android from the bsp too |
| 21:23.41 | libv | well, they will be in our github repo for some time, but i somehow feel that they shouldn't be in the HEAD of master after the current turmoil |
| 21:23.45 | mnemoc | in an integrated fashion |
| 21:23.48 | libv | mnemoc: ok |
| 21:24.05 | libv | mnemoc: who is working on that? |
| 21:24.41 | mnemoc | it's kind of low-prio |
| 21:24.48 | libv | seems like the android people are doing their own thing |
| 21:24.54 | libv | right, too much to do and too little time |
| 21:25.08 | mnemoc | yes, and they want one repo for each device |
| 21:25.25 | mnemoc | which at least in the sunxi world, it's plainly absurd |
| 21:25.58 | mnemoc | but I still have hope that day will come :) |
| 21:29.27 | libv | https://github.com/libv/mali-libs |
| 21:34.28 | mnemoc | libv: no crosscompiling support? |
| 21:36.12 | libv | nope, someone else can hack that in if he needs to |
| 21:36.26 | libv | same for debianization |
| 21:37.04 | libv | libump is rather tiny and does not take long on the a10 |
| 21:37.50 | mnemoc | but breaks rootfs generation |
| 21:38.05 | mnemoc | with mali-ump preincluded |
| 21:38.09 | libv | for me it just was real important to have these things installed correctly and painlessly with little option for error |
| 21:38.43 | libv | i have never generated a rootfs for sunxi |
| 21:38.45 | mnemoc | :) |
| 21:39.50 | libv | what is the wiki page with the explanation on how to do that? |
| 21:40.25 | hramrach | you don't need crosscompiling libump |
| 21:40.32 | libv | http://linux-sunxi.org/Buildroot ? |
| 21:40.34 | mnemoc | integration is currently done by sunxi-media-create |
| 21:40.47 | mnemoc | and mali libs are part of the hwpack |
| 21:41.02 | *** join/#arm-netbook tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 21:41.07 | hramrach | on debian you debootstrap and chroot into arm emu to do the rest of setup |
| 21:41.21 | hramrach | probably very similar on other distros |
| 21:41.30 | libv | Buildroot gets repos from matson-hall |
| 21:41.49 | hramrach | who would want to set up cross-libs for wole distro uselessly |
| 21:42.20 | mnemoc | i'll need to integrate the new sunxi-mali in the hwpack generation, and that is cross compiled |
| 21:42.57 | tzafrir_laptop | Hi. I see quite a few devices named like mk802. I gather none of them will run (proper) Linux, right? |
| 21:43.08 | mnemoc | but that isn't urgent as long as you don't delete the mali-libs repo ;-) |
| 21:43.18 | tzafrir_laptop | hramrach, s/debootstrap/qemu-debootstrap/ |
| 21:44.50 | libv | mnemoc: i will deprecate the mali-libs repo though |
| 21:44.54 | anunnaki | tzafrir_laptop, depends on your definition of "proper" but i believe there is a video on youtube with a guy running ubuntu on his mk802 |
| 21:45.00 | libv | so master from there will only contain a README |
| 21:45.12 | libv | mnemoc: how are you dealing with libump.so atm? |
| 21:45.29 | tzafrir_laptop | anunnaki, for starters, have proper kernel source. |
| 21:45.29 | mnemoc | cp :< |
| 21:45.42 | mnemoc | which is broken, i know |
| 21:45.42 | libv | libump.so was removed from mali-libs |
| 21:45.49 | *** join/#arm-netbook vinifm (~vini@177.19.132.23) |
| 21:45.59 | hramrach | I run debian on cubieboard ;-) |
| 21:46.00 | libv | as it was not working for r3p0/armhf/x11 |
| 21:46.05 | mnemoc | submodules are bound to certain commits, not branch heads |
| 21:46.26 | mnemoc | and hasn't been updated in a while |
| 21:46.33 | tzafrir_laptop | anunnaki, "mk802 III", "mk806" and such similar names. |
| 21:46.53 | mnemoc | but will need to find a way to cross compile libump.... yuck |
| 21:47.19 | hramrach | it has almost no dependencies |
| 21:47.32 | hramrach | and you can qemu-compile |
| 21:47.56 | libv | mnemoc: i am rather amazed, as r3p0/armhf/x11/libUMP.so and r3p0/armhf/x11/libMali.so were not good matches |
| 21:48.20 | libv | it might have been the faking of the X11 linking that was the issue |
| 21:48.40 | libv | in any case, direct copy of those would not result in decent working EGL/GLES system |
| 21:48.59 | anunnaki | tzafrir_laptop, well some of those are newer than others so I wouldnt expect much progress on the newest ones. I want to know the answer to that myself with the MK802IIIS. |
| 21:49.28 | mnemoc | libv: yes, i agree the concept is broken |
| 21:49.35 | libv | plus, well behaved X apps deadlock and other stuff on the libMali.so which is out there |
| 21:49.59 | libv | https://github.com/libv/mali-libs/commit/00e983dbac |
| 21:50.02 | anunnaki | tzafrir_laptop, or the GV-11 tvbox.. it has similar chip, but has a remote control. |
| 21:50.39 | libv | so we definitely need to fix this properly now :) |
| 21:52.34 | hramrach | well, the broken libUMP binary possibly came from upstream |
| 21:52.52 | hramrach | and nobody removed it |
| 21:53.43 | libv | make prefix=/../usr/ install :) |
| 21:55.32 | mnemoc | libv: on my defense, all that was inherited |
| 21:56.00 | libv | sure, but let's fix it up properly now :) |
| 21:56.08 | libv | well, tomorrow and the day after :) |
| 21:56.40 | libv | prefix= and VERSION= are the key, now i just need to add cross compilation |
| 22:26.35 | *** join/#arm-netbook XenGi (~XenGi@xengi.de) |
| 22:48.36 | *** join/#arm-netbook XenGi (~XenGi@xengi.de) |
| 22:56.25 | *** join/#arm-netbook Jef91 (~Instantbi@bodhilinux/team/Jef91) |
| 23:02.52 | *** join/#arm-netbook drachensun (~drachensu@142.196.83.182) |
| 23:49.55 | *** join/#arm-netbook Marex (~Marex@195.140.253.167) |
| 23:54.52 | *** join/#arm-netbook luka (~luka@62.113.232.79) |
| 23:59.07 | *** join/#arm-netbook tzafrir_laptop (~tzafrir@212.179.75.202) |