| 00:01.19 | ssvb | jelly-home: so far this one - https://github.com/ssvb/xf86-video-sunxifb/wiki/GentooLinuxSupport |
| 00:02.30 | ssvb | I could not build gnome-shell out of the box, I think it needs some linaro/ubuntu patches to make it GLES friendly |
| 00:03.25 | jelly-home | le sigh, I've managed to stay away from source-based distros since the last millennium |
| 00:05.01 | ssvb | though gnome-shell starts fine from the ubuntu chroot, so in theory it should not be too difficult to get working |
| 00:07.49 | jelly-home | well, replacing the desktop wouldn't have been my first idea on how to use an A10 box, but if it works... |
| 00:09.33 | *** join/#arm-netbook aexl_ (25059bf6@gateway/web/freenode/ip.37.5.155.246) |
| 00:09.55 | ssvb | hramrach: maybe they have a different package for kwin_gles in debian? |
| 00:10.11 | aexl_ | lo. does somebody have a statically linked abootimg? |
| 00:11.11 | jelly-home | ssvb: there is none in debian, I checked; Ubuntu however seems to have a http://packages.ubuntu.com/precise-updates/kde-window-manager-gles |
| 00:14.00 | jelly-home | "just" rebuilding kdebase-workspace source for armhf :-) |
| 00:14.20 | jelly-home | so much about binary-based distros |
| 00:14.52 | penguin42 | jelly-home: How long does that take on an a10 ? |
| 00:16.17 | jelly-home | penguin42: no idea -- personally I wouldn't build kde in 1GB |
| 00:16.42 | penguin42 | indeed |
| 00:16.48 | jelly-home | oh, ports.ubuntu.com has it |
| 00:20.58 | jelly-home | well. I _might_ try building it if I had an extra ssd to sacrify for build tree and swap space |
| 00:33.55 | ssvb | jelly-home: well, I just got fed up with this crap and decided to get a clean environment for checking what actually works with GLES and what does not |
| 00:34.49 | ssvb | jelly-home: gentoo is quite convenient, because it is a kinda meta-distribution which can be reconfigured as you wish |
| 00:36.14 | ssvb | jelly-home: I guess there are not many weirdos who would like to completely rip out the full OpenGL from their system :) |
| 00:41.18 | jelly-home | (or ones who don't have it at all like here) |
| 00:42.11 | hramrach | I suspect you can't remove it when you have Qt |
| 00:42.53 | hramrach | some stuff just links with it and the binaries include every feasible feature |
| 00:50.01 | FergusL | did anybody buy the Wandboard ? |
| 00:50.08 | *** join/#arm-netbook anunnakiii (~anunnaki@c-174-54-115-236.hsd1.pa.comcast.net) |
| 00:50.16 | ssvb | hramrach: it's not a problem if I can rebuild the whole system (all the Qt packages, etc.) |
| 00:52.30 | ssvb | hramrach: and now I also have an x86 system with exactly the same setup, should make it easier porting/debugging/comparing :) |
| 01:02.57 | *** join/#arm-netbook bfree (~niall@109.255.245.157) |
| 01:06.21 | *** join/#arm-netbook bfree_ (~niall@109.255.245.157) |
| 01:14.10 | *** join/#arm-netbook stefanro (~stefan@pD9FFB0B9.dip.t-dialin.net) |
| 01:52.26 | *** join/#arm-netbook alcides (~alcides@177.17.153.202) |
| 01:52.26 | *** join/#arm-netbook alcides (~alcides@unaffiliated/alcides) |
| 02:37.55 | *** join/#arm-netbook bfree__ (~niall@109.255.245.157) |
| 02:49.54 | *** join/#arm-netbook herdingcat (~huli@218.10.62.194) |
| 03:04.39 | jelly-home | FergusL: this is the first I even heard about it there's one interesting thing going for it -- EDM, 314 pins, existing before EOMA-68 happened |
| 03:05.19 | FergusL | ha jelly-home |
| 03:05.24 | FergusL | is that good ? |
| 03:06.22 | jelly-home | http://www.technexion.com/index.php/products/edm depends on how many vendors end up using it I guess |
| 03:07.02 | FergusL | yes, that's what they say in their wiki |
| 03:22.23 | *** join/#arm-netbook bfree (~niall@109.255.245.157) |
| 03:51.08 | *** join/#arm-netbook fragmint (~fragmint@108-77-196-171.lightspeed.tukrga.sbcglobal.net) |
| 04:26.53 | *** join/#arm-netbook aholler (~aholler@p57B2037B.dip0.t-ipconnect.de) |
| 04:30.57 | *** join/#arm-netbook KoH_ (~kane@trir-4d0bb775.pool.mediaWays.net) |
| 05:31.27 | *** join/#arm-netbook eebrah (~ibrah@212.49.88.101) |
| 05:31.51 | *** join/#arm-netbook bfree_ (~niall@109.255.245.157) |
| 05:35.51 | *** join/#arm-netbook xymox (lechuck@unaffiliated/contempt) |
| 05:43.24 | *** join/#arm-netbook xymox (~xymox@unaffiliated/contempt) |
| 06:07.58 | *** join/#arm-netbook sky770 (~sky770@122.177.225.162) |
| 06:32.33 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 06:46.00 | *** join/#arm-netbook gimli_ (~gimli@xbmc/staff/gimli) |
| 07:05.32 | *** join/#arm-netbook anunnaki (~anunnaki@c-174-54-115-236.hsd1.pa.comcast.net) |
| 07:31.13 | libv | heh, libump build seems quite retarded |
| 07:38.49 | libv | *sigh* |
| 07:55.57 | *** join/#arm-netbook hp__ (~kvirc@d5153E228.access.telenet.be) |
| 07:56.55 | *** join/#arm-netbook rellla (~rellla@p4FE5615F.dip0.t-ipconnect.de) |
| 08:07.37 | sky770 | libv: I thought, it was ARM's PRs |
| 08:07.42 | sky770 | :D |
| 08:14.42 | *** join/#arm-netbook hp__ (~kvirc@d5153E228.access.telenet.be) |
| 08:18.17 | libv | tonight, i am going to make the libump repo redudant. |
| 08:18.25 | libv | redundant even |
| 08:19.36 | *** join/#arm-netbook Quarx (~Quarx@176.62.118.104) |
| 08:20.20 | *** join/#arm-netbook eFfeM (~frans@c73189.upc-c.chello.nl) |
| 08:23.11 | sky770 | omfg :O ppl at #ubuntu don't even know the diff b/w "ubuntu for phones" & "ubuntu for android" |
| 08:23.24 | sky770 | *dammnit* :| |
| 08:37.35 | *** join/#arm-netbook TimeBreaker (2a7848af@gateway/web/freenode/ip.42.120.72.175) |
| 08:56.02 | *** join/#arm-netbook cnxsoft (~cnxsoft@node-ahd.pool-118-172.dynamic.totbb.net) |
| 09:40.35 | *** join/#arm-netbook ganbold__ (~Ganbold@202.21.108.27) |
| 09:50.47 | *** join/#arm-netbook w00tc0d3 (~smuxi@unaffiliated/w00tc0d3) |
| 10:17.37 | *** join/#arm-netbook rz2k (~rz2k@93-80-85-167.broadband.corbina.ru) |
| 10:27.34 | *** join/#arm-netbook wingrime (~wingrime@78.109.115.103) |
| 10:32.16 | *** join/#arm-netbook abesis (~abesis@217.131.210.89) |
| 11:24.44 | *** join/#arm-netbook eFfeM (~frans@c73189.upc-c.chello.nl) |
| 11:37.21 | *** join/#arm-netbook abesis (~abesis@217.131.210.89) |
| 11:39.46 | mnemoc | libv: you mean a lima version of arm's libump? |
| 12:02.30 | *** join/#arm-netbook focus_it (~focus_it@cpc7-dals17-2-0-cust182.hari.cable.virginmedia.com) |
| 12:10.41 | *** join/#arm-netbook sky770 (~sky770@122.177.225.162) |
| 12:13.57 | *** join/#arm-netbook penguin42 (~dg@tu006.demon.co.uk) |
| 12:15.06 | sky770 | #ubuntu-phone is coming!! dev touch review this 21st :p :p |
| 12:19.59 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 12:31.34 | specing | sky770: all fine with me if it is not going to be overpriced like neo freerunner |
| 12:32.48 | *** join/#arm-netbook cnxsoft (~cnxsoft@node-ahd.pool-118-172.dynamic.totbb.net) |
| 12:41.27 | *** join/#arm-netbook eFfeM (~frans@c73189.upc-c.chello.nl) |
| 12:43.29 | *** join/#arm-netbook aesok (~aesok@128-72-132-189.broadband.corbina.ru) |
| 12:53.04 | *** join/#arm-netbook OmegaPhil (~kvirc@82-71-20-171.dsl.in-addr.zen.co.uk) |
| 12:53.04 | *** join/#arm-netbook OmegaPhil (~kvirc@fsf/member/OmegaPhil) |
| 12:59.33 | sky770 | specing: "overpriced" ? lol ..I was talking abt Ubuntu for phones "OS" * :p |
| 12:59.57 | hramrach | they are developing hardware too |
| 13:04.42 | sky770 | hramrach: not exactly..but they're roping in OEM's for that thing |
| 13:04.51 | sky770 | Huawei being one of them :| |
| 13:05.30 | sky770 | suspects chinese low quality built phones ..*nuff* |
| 13:05.49 | sky770 | no offence * :D |
| 13:06.58 | sky770 | bad thing about the dev. preview this 21st is that there won't be any support apart from nexus/nexus 4 (well..atleast on that day..or even some days after..) |
| 13:07.40 | sky770 | devices will eventually get added in the support list depending on indie devs getting "interested" in porting ubuntu to a particualr handset :| |
| 13:07.58 | sky770 | well more info to come during/after this MWC :D |
| 13:08.12 | sky770 | 25-28th feb :) |
| 13:09.17 | OmegaPhil | 'A signature flourish for Ubuntu and for you.' |
| 13:09.20 | OmegaPhil | jesus christ |
| 13:10.31 | sky770 | ? :( |
| 13:10.48 | sky770 | amen.. ? :D |
| 13:11.49 | OmegaPhil | I'll get him on the phone and have a talk about what I read |
| 13:32.00 | *** join/#arm-netbook hansg (~hans@ip32-174-211-87.adsl2.static.versatel.nl) |
| 13:33.50 | ssvb | libv: what's the motivation for making libump redundant? |
| 13:57.31 | *** part/#arm-netbook FergusL (~PetitLol@2a01:e0b:1000:33:5054:ff:fe00:1d0) |
| 14:07.53 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 14:48.00 | *** join/#arm-netbook rellla2 (~rellla@p4FE5615F.dip0.t-ipconnect.de) |
| 14:49.32 | *** join/#arm-netbook rellla1 (~Thunderbi@p4FE5615F.dip0.t-ipconnect.de) |
| 15:01.46 | libv | ssvb: i want to fold it in with mali-libs, in such a way that things get built and installed in one go |
| 15:01.58 | libv | mnemoc: nope |
| 15:02.25 | libv | the current setup is a mess, and leads to issues all around |
| 15:04.10 | libv | libump will be built from source, and will only get the X11 dependencies when make x11 is run |
| 15:04.32 | libv | for framebuffer, it will be built without those dependencies |
| 15:04.50 | libv | all the existing libump.sos will be removed from mali-libs |
| 15:05.06 | libv | suddenly, this thing will make sense and will be useful. |
| 15:06.46 | libv | oh, libump will be built from source, and the depending on the kernel version, the right version of it will be built too |
| 15:07.09 | libv | no more of this multiple branches nonsense |
| 15:10.34 | libv | there really is no reason to carry both the binaries and the source around |
| 15:10.55 | libv | we need to build from source anyway to work around linking issues, so the binaries go |
| 15:12.02 | ssvb | libv: ok, I just thought that we already build it from sources |
| 15:13.52 | libv | ssvb: no, we first install the binary |
| 15:14.00 | libv | and then the howto tells you to build from source |
| 15:14.10 | libv | which then gets you the X11 libs linked in |
| 15:14.12 | ssvb | but you fixed it already? |
| 15:14.26 | libv | only for r3p0/hf/x11 |
| 15:14.31 | ssvb | ok |
| 15:14.41 | libv | so the current setup is a complete mess. |
| 15:14.55 | techn__ | true |
| 15:15.02 | ssvb | yes, no disagreement here :) |
| 15:15.03 | libv | what we will get is a one-shot install. |
| 15:15.21 | ssvb | what's going to happen to https://github.com/linux-sunxi/libump ? |
| 15:15.38 | libv | master should become an empty commit |
| 15:15.48 | libv | it is not as if it is tracking ARM code releases anyway |
| 15:15.48 | techn__ | apt installable package would be nice too.. which will tell packaging management not to install mesa stuff |
| 15:16.13 | libv | techn__: as the main author of the lima driver, i find it amazing that i am having to spend so much time making sense in all of this myself already |
| 15:16.14 | *** join/#arm-netbook ganbold_ (~Ganbold@202.21.108.27) |
| 15:16.20 | libv | surely others see the problems with this too |
| 15:16.34 | libv | then why do i end up being the one fixing such brokenness here? |
| 15:16.52 | libv | so no, i am not going to provide a debian subdirectory |
| 15:16.59 | ssvb | sorry, you lost me here |
| 15:17.27 | libv | i already am pretty unhappy about the fact that noone else could've been arsed to fix up the test for x11 |
| 15:17.49 | libv | apart from a binary hack to libMali.so, making that test also run on x11 was really trivial |
| 15:19.12 | ssvb | yes, but apparently nobody was interested in this test |
| 15:19.36 | ssvb | you are interested, so you fixed it, problem solved |
| 15:19.54 | ssvb | thanks, that's surely appreciated |
| 15:19.55 | libv | ssvb: yet techn__ merged in a single commit to help explain why it was not working on X11 |
| 15:20.22 | libv | and every week or so, someone would come round and explain |
| 15:20.29 | libv | s/explain/complain/ |
| 15:20.56 | libv | but no, i am not wasting my time on debian packaging this thing as well |
| 15:21.10 | ssvb | neither do I :) |
| 15:22.09 | techn__ | .. was it sky770 who is taking initiative as package maintainer :/ |
| 15:22.10 | hramrach | packaging this is pretty much impossible with two different sets of libraries |
| 15:25.05 | ssvb | packaging is problematic because of the missing license notice for the mali binaries, I would guess a lot of people are avoiding to touch this stuff simply for this reason |
| 15:25.40 | libv | nope, people are just lazy |
| 15:26.37 | ssvb | that's also true, but surely not the only reason |
| 15:26.57 | libv | in this case, it is |
| 15:27.35 | ssvb | let's ask hansg about what he thinks about packaging mali drivers for fedora ;) |
| 15:28.22 | libv | ssvb: hansg has better things to do |
| 15:28.38 | ssvb | we all have better things to do |
| 15:28.56 | libv | heh |
| 15:29.19 | libv | ssvb: how many people have come round and said "why is there no packages for this" |
| 15:29.48 | hramrach | never heard anyone saying it |
| 15:30.09 | libv | ssvb: how many of those were even considering doin the busywork that is creating packages? |
| 15:30.38 | libv | ssvb: how many of the remaining, which is none, were then stopped by the fact that there were binaries in there which do not come with a license? |
| 15:31.20 | hramrach | presumably the stuff is pacakged for gentoo |
| 15:32.02 | ssvb | hramrach: not officially :) but I'm ready to provide help to anyone trying to use this stuff |
| 15:32.03 | hramrach | which is pretty much the only distro which can bear the current quality of the code |
| 15:32.59 | bfree_ | I've done some work on deb packaging, but so far I've only worked on the kernel and uboot (ok I started to look at sunxi-tools the other day). I've not even touched any video stuff myself yet (apart from just what is in Debian to confirm X will come up), let alone considered attempting to package it |
| 15:37.54 | *** join/#arm-netbook vinifm (~Vinicius@177.98.219.60) |
| 15:39.37 | hramrach | the driver released by hardkernel is even better |
| 15:39.45 | hramrach | it has copyright notice |
| 15:40.11 | hramrach | it says you can run it on snowball - an Ericsson evb |
| 15:40.24 | hramrach | and only that board |
| 15:40.41 | hramrach | not, say, an Odroid or mk802 |
| 15:42.25 | ssvb | lol, have you reported it to hardkernel people? |
| 15:42.51 | ssvb | looks like somebody copy-pasted too much |
| 15:43.52 | ssvb | but at least they are trying to do it right |
| 15:52.34 | ssvb | looks like so far only raspberry pi has done the right thing with the blob gpu drivers for arm hardware (if we ignore their shameless marketing) |
| 15:54.08 | ssvb | for raspberry pi we have all the firmware releases backed up in a freely accessible git repository, accompanied with a license which explicitly allows redistribution. IMHO that's about the best possible way to handle it, assuming that the firmware sources have to be kept closed. |
| 15:55.50 | hramrach | no, I did not report it |
| 15:56.23 | libv | ssvb: does your xf86 driver use libump headers? |
| 15:56.39 | ssvb | libv: yes |
| 15:57.20 | libv | ok |
| 16:20.11 | ssvb | hramrach: ok, now I did - http://odroid.foros-phpbb.com/t2416p50-linaro-ubuntu-1211-for-odroid-x#19691 |
| 16:28.48 | *** join/#arm-netbook blindcoder (~blindcode@pallas.crash-override.net) |
| 16:28.53 | blindcoder | hello |
| 16:29.04 | blindcoder | am I right here for the pengpod? |
| 16:29.36 | blindcoder | I want to compile my own kernel for it (need the /dev/snd/seq device) and wonder where to get the kernel sources |
| 16:30.31 | ssvb | hramrach: but assuming that they announce it as "You can enjoy the Mali400 OpenGL-ES 3D software develoment", there is little hope for the casual end users who actually want to use this shit, and not "develop" for it :-/ |
| 16:31.02 | RaYmAn | blindcoder: Surely "True Linux Tablets and MiniPCs" provide kernel source along with the device. |
| 16:31.24 | Turl | blindcoder: https://github.com/linux-sunxi/linux-sunxi |
| 16:31.30 | blindcoder | Turl: thanks! |
| 16:31.55 | blindcoder | Turl: I want to connect it to my midi keyboard using pianobooster, and that needs the /dev/snd/seq device. |
| 16:32.03 | RaYmAn | There's no really any pengpod specific development. They just use the general A10 development happening. |
| 16:41.43 | drachensun | blindcoder: we have a #pengpod channel too |
| 16:52.35 | blindcoder | drachensun: ah, cool |
| 17:03.41 | *** join/#arm-netbook roric_ (~roric@c-9370e455.213-3-64736c14.cust.bredbandsbolaget.se) |
| 17:40.38 | *** join/#arm-netbook panurge (~thiago@177.191.95.80) |
| 18:00.25 | *** join/#arm-netbook anunnaki (~anunnaki@c-174-54-115-236.hsd1.pa.comcast.net) |
| 18:13.18 | *** join/#arm-netbook abesis2 (~abesis@217.131.210.89) |
| 18:26.45 | *** join/#arm-netbook ZaEarl (~malmrose@c-67-172-235-190.hsd1.ut.comcast.net) |
| 18:27.21 | *** join/#arm-netbook panurgebr (~thiago@177.191.174.78) |
| 18:53.39 | slapin | hi, all? |
| 18:54.47 | anunnaki | im testing crosscompiling a sample file from a guide im following. and it says to emerge qemu. should i do 'USE="arm -x86_64" emerge qemu' or will simply emerge qemu suffice? |
| 18:55.14 | slapin | is there some tool to route ddr3 running under Linux? |
| 18:55.43 | *** join/#arm-netbook jukivili (~jussi@dalek.fi) |
| 18:56.05 | slapin | as I find it too boring to calculate impedance by hand |
| 18:56.06 | anunnaki | my target arch is arm, this host pc is x86_64 |
| 18:56.46 | *** part/#arm-netbook blindcoder (~blindcode@pallas.crash-override.net) |
| 18:57.21 | anunnaki | please use my name if you answer my question for ill be jumping channels. thanks guys |
| 19:13.12 | *** join/#arm-netbook rellla (~Thunderbi@p4FE5615F.dip0.t-ipconnect.de) |
| 19:26.00 | *** join/#arm-netbook eebrah (~ibrah@212.49.88.100) |
| 19:34.39 | *** join/#arm-netbook FergusL (~PetitLol@2a01:e0b:1000:33:5054:ff:fe00:1d0) |
| 19:38.38 | Turl | pogoplugs for 19$ each http://www.adorama.com/COCPOGOP21.html |
| 19:44.17 | jinzo | yeah, a bit expensive shipping if you're not in US |
| 19:44.20 | jinzo | but still, a nice deal. |
| 19:46.43 | Turl | apparently that specific model is not mainline supported though |
| 19:56.24 | *** join/#arm-netbook muts (~muts@backtrack/leader/muts) |
| 20:01.21 | jinzo | I stumbled on the new pogoplugs, the one with USB 3.0 and SATA looks quite interesting at a nice price point |
| 20:09.53 | *** join/#arm-netbook anunnaki (~anunnaki@c-174-54-115-236.hsd1.pa.comcast.net) |
| 20:21.12 | *** join/#arm-netbook w00tc0d3 (~smuxi@unaffiliated/w00tc0d3) |
| 20:32.12 | *** join/#arm-netbook anunnaki (~anunnaki@c-174-54-115-236.hsd1.pa.comcast.net) |
| 20:55.19 | *** join/#arm-netbook hramrach (~hramrach@gateway/tor-sasl/hramrach) |
| 20:55.28 | buZz | http://www.aliexpress.com/item/quad-core-tablet-pc-9-7-inch-Onda-V972-quad-core-Tablet-PC-HDMI-Allwinner-A31/735365952.html |
| 20:55.34 | buZz | woa,, A31 being released? |
| 20:55.59 | jinzo | buZz, shipping for quite some time now. ~mid jan. |
| 20:56.02 | jinzo | or somewhere there. |
| 20:56.47 | buZz | nice |
| 20:56.55 | buZz | is A20 then also released? |
| 20:57.05 | jinzo | haven't seen anything shipping with it yet. |
| 20:57.29 | jinzo | didn't even notice any preorders floating around (but I'm not following this stuff that much nowadays) |
| 21:06.16 | techn__ | got simplest drm driver skeleton working.. with no hw calls.. but should help things to get started :/ |
| 21:08.25 | techn__ | .. but it's still not ready to spread around.. but if there is volunteers to participate developing.. I could try to push it during next week |
| 21:17.47 | *** join/#arm-netbook eFfeM (~frans@c73189.upc-c.chello.nl) |
| 21:23.33 | libv | techn__: drm driver to do what with? |
| 21:24.11 | techn__ | libv: Currently it creates dummy bindings for /dev/fb and sysfs |
| 21:24.20 | *** join/#arm-netbook ZaEarl (~malmrose@c-67-172-235-190.hsd1.ut.comcast.net) |
| 21:24.35 | libv | techn__: and the goal is? |
| 21:25.47 | techn__ | short term.. to get simple framebuffer which uses normal layer (no scaling) and hdmi |
| 21:26.34 | techn__ | long term.. whole disp to mainline |
| 21:27.55 | techn__ | but.. if someone wants to implement TCON0 and LCD, RGB or tvout for short term, its welcomed too :p |
| 21:28.27 | libv | it's the wrong approach |
| 21:28.59 | libv | one that leads to dumbing down of our userbase and the loss of register level information |
| 21:29.55 | libv | techn__: the correct way to approach this is to clean up and restructure disp and then add drm kms support on top of the then clean and structured code |
| 21:31.17 | hramrach | how is register level information lost? |
| 21:31.18 | techn__ | If we want refactor current driver we need to do it twice.. with huge regression risk.. first to get it cleaned top of old arch.. then move it to drm/kms.. |
| 21:31.42 | libv | nope |
| 21:31.56 | hramrach | no move if you just add kms glue on top |
| 21:32.08 | libv | you are, at best, creating a situation where you have two different drivers, both broken in different ways, and no possibility to fix either |
| 21:32.12 | techn__ | and this current driver is suffering issues which comes free for drm/kms |
| 21:32.46 | libv | and there is little regression risk when cleaning/restructuring properly |
| 21:32.58 | libv | but that does require patience and clue |
| 21:33.06 | techn__ | like improved page flipping and architecture for dual display |
| 21:33.19 | libv | for free? |
| 21:33.22 | libv | really? |
| 21:33.33 | hramrach | the architecture for dual display does not come out of nowhere |
| 21:33.39 | libv | you'll have to explain the mechanics of that "for free" to me then |
| 21:33.48 | hramrach | you still ahve to figure out how to configure it with the actual hardware |
| 21:34.22 | libv | techn__: in any case, if you want to do something useful, and want to play with kms |
| 21:34.40 | libv | try bolting kms on top of the current disp and try to sensibly restructure disp underneath it |
| 21:34.59 | libv | the approach you are taking now is just stupid, and will only lead to further stagnation |
| 21:36.55 | *** part/#arm-netbook FergusL (~PetitLol@2a01:e0b:1000:33:5054:ff:fe00:1d0) |
| 21:37.32 | libv | it is however something one thinks off on a sunday afternoon |
| 21:37.58 | libv | but believe me, there are much better things to do, which actually will help us along long and short term |
| 21:39.13 | libv | techn__: for an example of the sort of kamikaze stupidity you are running into: the openchrome driver |
| 21:39.16 | techn__ | I just hate to see that if I do something for current module I have to do it again in future |
| 21:39.36 | techn__ | libv: I understand that |
| 21:39.40 | libv | they forked away from me because i did not want to accept VBE based modesetting |
| 21:40.07 | libv | today, they have 3 different modesetting paths and the few remaining openchrome users try each of the three until one of them sort of works |
| 21:40.20 | libv | nothing ever gets fixed. |
| 21:40.40 | libv | techn__: use your spare time/energy elsewhere then |
| 21:42.36 | *** join/#arm-netbook sv (~discopig@unaffiliated/discopig) |
| 22:25.31 | ssvb | techn__: I agree with libv, there way too many examples which show that the drm/kms, wayland, ... <insert some other trendy new thing here> .... is not the silver bullet |
| 22:27.06 | ssvb | techn__: there is a good explanation in "Fire And Motion" by Joel Spolsky - http://www.joelonsoftware.com/articles/fog0000000339.html |
| 22:27.57 | ssvb | techn__: the part about "Watch out when your competition fires at you. Do they just want to force you to keep busy reacting to their volleys, so you can't move forward?" :) |
| 22:29.33 | ssvb | techn__: and just substitute "ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET - All New!" with the things relevant to us - "DRM/KMS, V4L2, Wayland, ..." |
| 22:30.26 | libv | disp is a dead-end, it should die |
| 22:30.34 | libv | but it should die slowly, through dissection |
| 22:30.49 | libv | there is loads of very relevant information in there |
| 22:30.55 | libv | which we simply cannot afford to lose |
| 22:31.13 | ssvb | yes, exactly |
| 22:31.19 | libv | the way to do it is to restructure it, and then bolt something better on top |
| 22:31.26 | libv | not by starting afresh |
| 22:31.34 | libv | you get absolutely nothing for free when starting afresh |
| 22:31.43 | libv | and you throw out the baby with the bathwater while doing so |
| 22:31.59 | libv | and only then does the openchrome syndrome kick in |
| 22:32.11 | libv | which then kills _everything_ |
| 22:32.21 | anunnaki | hi need help with qemu. im following this guide http://psas.pdx.edu/GentooCrossComipilerHowTo/ |
| 22:33.16 | anunnaki | and when i get to Run the test program step. i typed qemu-arm ./hello i get "qemu-arm command not found" |
| 22:33.41 | anunnaki | i also tried qemu-armv4 ./hello as well.. same result |
| 22:34.15 | anunnaki | i also emerged qemu with the arm use flag.. no change in result |
| 22:34.28 | libv | hrm... |
| 22:34.30 | ssvb | libv: many of the remaining bugs in disp are still fixable, and it is possible to get a somewhat sane graphics stack running on top of it, this requires less efforts than full rewrite |
| 22:34.51 | mnemoc | +1 |
| 22:35.18 | ssvb | anunnaki: please check http://www.gentoo.org/proj/en/base/embedded/handbook/?part=1&chap=5 |
| 22:35.29 | libv | ssvb: to what extent does xf86-video-mali depend on ump, does it depend on any of the newer symbols that r3p0 (and up, as that's all the same) provides? |
| 22:36.05 | ssvb | libv: the real problem is that libMali.so depends on ump |
| 22:36.11 | libv | ssvb: i am struggling with introducing versioning on the headers |
| 22:36.18 | libv | i haven't figured out what the best route is |
| 22:36.24 | libv | oh, that one is easy |
| 22:36.42 | libv | my current code just installs the r3 headers |
| 22:36.54 | libv | as there are no abi breakages in there |
| 22:37.02 | libv | there are only additions to the api |
| 22:37.27 | libv | and things will break trying to link to an r2 ump while assuming that you are building against the full api exposed in these headers |
| 22:38.18 | libv | i am currently thinking about echoing a version into ump_version.h |
| 22:38.34 | libv | but this then requires proper dependency tracking when building libUMP.so |
| 22:39.26 | ssvb | r3 version of libump introduces buffers cacheability control, but I think this should be already covered - https://github.com/ssvb/xf86-video-sunxifb/blob/master/configure.ac#L89 |
| 22:39.57 | libv | aha, check_lib |
| 22:40.00 | libv | nice |
| 22:41.05 | ssvb | well, maybe not totally nice and reliable, but we are yet to see a bugreport about it failing |
| 22:41.25 | libv | still, it would be better if some #define introduced from ump.h would help delineate this |
| 22:41.44 | libv | oh, it is reliable, but it is not the cleanest solution |
| 22:41.52 | libv | it could make life real easy for me though |
| 22:42.36 | ssvb | there always could be a mismatch between the headers and the libraries or something like this |
| 22:59.24 | *** join/#arm-netbook aholler (~aholler@p57B2037B.dip0.t-ipconnect.de) |
| 23:11.25 | *** join/#arm-netbook FergusL (~PetitLol@2a01:e0b:1000:33:5054:ff:fe00:1d0) |
| 23:37.24 | libv | heh, exploding complexity... |
| 23:38.44 | libv | so i guess i will keep version out of the headers for now |