<jelly-home>
"just" rebuilding kdebase-workspace source for armhf :-)
<jelly-home>
so much about binary-based distros
<penguin42>
jelly-home: How long does that take on an a10 ?
marcus__ has quit [Remote host closed the connection]
<jelly-home>
penguin42: no idea -- personally I wouldn't build kde in 1GB
<penguin42>
indeed
<jelly-home>
oh, ports.ubuntu.com has it
<jelly-home>
well. I _might_ try building it if I had an extra ssd to sacrify for build tree and swap space
<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
<ssvb>
jelly-home: gentoo is quite convenient, because it is a kinda meta-distribution which can be reconfigured as you wish
<ssvb>
jelly-home: I guess there are not many weirdos who would like to completely rip out the full OpenGL from their system :)
aesok has quit [Remote host closed the connection]
<jelly-home>
(or ones who don't have it at all like here)
<hramrach>
I suspect you can't remove it when you have Qt
<hramrach>
some stuff just links with it and the binaries include every feasible feature
anunnaki has quit [Quit: Leaving]
<FergusL>
did anybody buy the Wandboard ?
anunnakiii has joined #arm-netbook
<ssvb>
hramrach: it's not a problem if I can rebuild the whole system (all the Qt packages, etc.)
anunnakiii is now known as anunnaki
<ssvb>
hramrach: and now I also have an x86 system with exactly the same setup, should make it easier porting/debugging/comparing :)
XenGi is now known as XenGi_
bfree has quit [Ping timeout: 252 seconds]
bfree has joined #arm-netbook
bfree_ has joined #arm-netbook
bfree has quit [Ping timeout: 252 seconds]
stefanro has joined #arm-netbook
hp__ has quit [Ping timeout: 264 seconds]
stefanro1 has quit [Ping timeout: 260 seconds]
alcides has joined #arm-netbook
alcides has joined #arm-netbook
alcides has quit [Changing host]
alcides has quit [Quit: /(bb|[^b]{2})/ regular expression junkie + lover of literature...]
focus_it has quit [Remote host closed the connection]
XenGi_ is now known as XenGi
dfletcher is now known as drgreenthumb
bfree__ has joined #arm-netbook
bfree_ has quit [Ping timeout: 252 seconds]
herdingcat has joined #arm-netbook
aexl_ has quit [Quit: Page closed]
<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
fragmint has quit [Read error: Connection reset by peer]
fragmint has joined #arm-netbook
aholler has joined #arm-netbook
aholler_ has quit [Ping timeout: 248 seconds]
KoH_ has joined #arm-netbook
KoH__ has quit [Ping timeout: 248 seconds]
eebrah has joined #arm-netbook
bfree has quit [Ping timeout: 252 seconds]
bfree_ has joined #arm-netbook
xymox has quit [Ping timeout: 260 seconds]
xymox has joined #arm-netbook
xymox has quit [Ping timeout: 276 seconds]
xymox has joined #arm-netbook
sky770 has joined #arm-netbook
gimli has joined #arm-netbook
gimli has quit [Read error: Connection reset by peer]
gimli_ has joined #arm-netbook
gimli_ is now known as gimli
anunnaki has quit [Remote host closed the connection]
anunnaki has joined #arm-netbook
<libv>
heh, libump build seems quite retarded
<libv>
*sigh*
hp__ has joined #arm-netbook
rellla has joined #arm-netbook
<sky770>
libv: I thought, it was ARM's PRs
<sky770>
:D
hp__ has quit [Ping timeout: 264 seconds]
hp__ has joined #arm-netbook
<libv>
tonight, i am going to make the libump repo redudant.
<libv>
redundant even
Quarx has joined #arm-netbook
eFfeM has joined #arm-netbook
<sky770>
omfg :O ppl at #ubuntu don't even know the diff b/w "ubuntu for phones" & "ubuntu for android"
* sky770
*dammnit* :|
TimeBreaker has joined #arm-netbook
TimeBreaker has quit [Client Quit]
cnxsoft has joined #arm-netbook
anunnaki has quit [Ping timeout: 256 seconds]
eFfeM has quit [Quit: Leaving.]
ganbold__ has joined #arm-netbook
ganbold_ has quit [Ping timeout: 248 seconds]
w00tc0d3 has quit [Remote host closed the connection]
w00tc0d3 has joined #arm-netbook
sky770 has quit []
abesis2 has quit [Ping timeout: 240 seconds]
rz2k has joined #arm-netbook
wingrime has joined #arm-netbook
Quarx has quit []
abesis has joined #arm-netbook
eFfeM has joined #arm-netbook
Guest94707 is now known as fredy
fredy is now known as Guest77256
abesis has quit [Ping timeout: 245 seconds]
abesis has joined #arm-netbook
<mnemoc>
libv: you mean a lima version of arm's libump?
cnxsoft has quit [Quit: cnxsoft]
gimli has quit [Ping timeout: 248 seconds]
focus_it has joined #arm-netbook
sky770 has joined #arm-netbook
penguin42 has joined #arm-netbook
* sky770
#ubuntu-phone is coming!! dev touch review this 21st :p :p
gimli has joined #arm-netbook
eFfeM has quit [Ping timeout: 260 seconds]
jukivili has quit [Ping timeout: 245 seconds]
gimli has quit [Ping timeout: 252 seconds]
<specing>
sky770: all fine with me if it is not going to be overpriced like neo freerunner
cnxsoft has joined #arm-netbook
eFfeM has joined #arm-netbook
aesok has joined #arm-netbook
OmegaPhil has quit []
OmegaPhil has joined #arm-netbook
OmegaPhil has quit [Changing host]
OmegaPhil has joined #arm-netbook
<sky770>
specing: "overpriced" ? lol ..I was talking abt Ubuntu for phones "OS" * :p
<hramrach>
they are developing hardware too
<sky770>
hramrach: not exactly..but they're roping in OEM's for that thing
<sky770>
Huawei being one of them :|
* sky770
suspects chinese low quality built phones ..*nuff*
* sky770
no offence * :D
<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..)
<sky770>
devices will eventually get added in the support list depending on indie devs getting "interested" in porting ubuntu to a particualr handset :|
<sky770>
well more info to come during/after this MWC :D
<sky770>
25-28th feb :)
<OmegaPhil>
'A signature flourish for Ubuntu and for you.'
<OmegaPhil>
jesus christ
<sky770>
? :(
<sky770>
amen.. ? :D
<OmegaPhil>
I'll get him on the phone and have a talk about what I read
cnxsoft has quit [Ping timeout: 256 seconds]
hansg has joined #arm-netbook
<ssvb>
libv: what's the motivation for making libump redundant?
FergusL has left #arm-netbook ["Quit"]
gimli has joined #arm-netbook
sky770 has quit []
rellla2 has joined #arm-netbook
rellla1 has joined #arm-netbook
<libv>
ssvb: i want to fold it in with mali-libs, in such a way that things get built and installed in one go
<libv>
mnemoc: nope
<libv>
the current setup is a mess, and leads to issues all around
<libv>
libump will be built from source, and will only get the X11 dependencies when make x11 is run
<libv>
for framebuffer, it will be built without those dependencies
<libv>
all the existing libump.sos will be removed from mali-libs
<libv>
suddenly, this thing will make sense and will be useful.
<libv>
oh, libump will be built from source, and the depending on the kernel version, the right version of it will be built too
<libv>
no more of this multiple branches nonsense
<libv>
there really is no reason to carry both the binaries and the source around
<libv>
we need to build from source anyway to work around linking issues, so the binaries go
<ssvb>
libv: ok, I just thought that we already build it from sources
<libv>
ssvb: no, we first install the binary
<libv>
and then the howto tells you to build from source
<libv>
it is not as if it is tracking ARM code releases anyway
<techn__>
apt installable package would be nice too.. which will tell packaging management not to install mesa stuff
<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
ganbold_ has joined #arm-netbook
<libv>
surely others see the problems with this too
<libv>
then why do i end up being the one fixing such brokenness here?
<libv>
so no, i am not going to provide a debian subdirectory
<ssvb>
sorry, you lost me here
<libv>
i already am pretty unhappy about the fact that noone else could've been arsed to fix up the test for x11
<libv>
apart from a binary hack to libMali.so, making that test also run on x11 was really trivial
<ssvb>
yes, but apparently nobody was interested in this test
ganbold__ has quit [Ping timeout: 252 seconds]
<ssvb>
you are interested, so you fixed it, problem solved
<ssvb>
thanks, that's surely appreciated
<libv>
ssvb: yet techn__ merged in a single commit to help explain why it was not working on X11
<libv>
and every week or so, someone would come round and explain
<libv>
s/explain/complain/
<ibot>
libv meant: and every week or so, someone would come round and complain
<libv>
but no, i am not wasting my time on debian packaging this thing as well
<ssvb>
neither do I :)
<techn__>
.. was it sky770 who is taking initiative as package maintainer :/
<hramrach>
packaging this is pretty much impossible with two different sets of libraries
<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
<libv>
nope, people are just lazy
<ssvb>
that's also true, but surely not the only reason
<libv>
in this case, it is
<ssvb>
let's ask hansg about what he thinks about packaging mali drivers for fedora ;)
<libv>
ssvb: hansg has better things to do
<ssvb>
we all have better things to do
<libv>
heh
<libv>
ssvb: how many people have come round and said "why is there no packages for this"
<hramrach>
never heard anyone saying it
<libv>
ssvb: how many of those were even considering doin the busywork that is creating packages?
<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?
<hramrach>
presumably the stuff is pacakged for gentoo
<ssvb>
hramrach: not officially :) but I'm ready to provide help to anyone trying to use this stuff
<hramrach>
which is pretty much the only distro which can bear the current quality of the code
<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
bfree_ is now known as bfree
vinifm has joined #arm-netbook
<hramrach>
the driver released by hardkernel is even better
<hramrach>
it has copyright notice
<hramrach>
it says you can run it on snowball - an Ericsson evb
<hramrach>
and only that board
<hramrach>
not, say, an Odroid or mk802
<ssvb>
lol, have you reported it to hardkernel people?
herdingcat has quit [Remote host closed the connection]
<ssvb>
looks like somebody copy-pasted too much
<ssvb>
but at least they are trying to do it right
rellla has quit [Remote host closed the connection]
<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)
<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.
<hramrach>
no, I did not report it
<libv>
ssvb: does your xf86 driver use libump headers?
<blindcoder>
I want to compile my own kernel for it (need the /dev/snd/seq device) and wonder where to get the kernel sources
<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 :-/
<RaYmAn>
blindcoder: Surely "True Linux Tablets and MiniPCs" provide kernel source along with the device.
<blindcoder>
Turl: I want to connect it to my midi keyboard using pianobooster, and that needs the /dev/snd/seq device.
<RaYmAn>
There's no really any pengpod specific development. They just use the general A10 development happening.
rellla1 has quit [Ping timeout: 240 seconds]
rellla2 has quit [Ping timeout: 248 seconds]
ganbold_ has quit [Remote host closed the connection]
<drachensun>
blindcoder: we have a #pengpod channel too
hansg has quit [Remote host closed the connection]
<blindcoder>
drachensun: ah, cool
roric_ has joined #arm-netbook
eFfeM has quit [Quit: Leaving.]
panurge has joined #arm-netbook
anunnaki has joined #arm-netbook
abesis has quit [Ping timeout: 252 seconds]
abesis2 has joined #arm-netbook
hramrach has quit [Remote host closed the connection]
ZaEarl has joined #arm-netbook
panurgebr has joined #arm-netbook
panurge has quit [Ping timeout: 256 seconds]
wingrime has quit [Ping timeout: 255 seconds]
<slapin>
hi, all?
<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?
<slapin>
is there some tool to route ddr3 running under Linux?
jukivili has joined #arm-netbook
<slapin>
as I find it too boring to calculate impedance by hand
<anunnaki>
my target arch is arm, this host pc is x86_64
blindcoder has left #arm-netbook [#arm-netbook]
<anunnaki>
please use my name if you answer my question for ill be jumping channels. thanks guys
w00tc0d3 has quit [Remote host closed the connection]
<jinzo>
buZz, shipping for quite some time now. ~mid jan.
<jinzo>
or somewhere there.
<buZz>
nice
<buZz>
is A20 then also released?
<jinzo>
haven't seen anything shipping with it yet.
<jinzo>
didn't even notice any preorders floating around (but I'm not following this stuff that much nowadays)
<techn__>
got simplest drm driver skeleton working.. with no hw calls.. but should help things to get started :/
<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
eFfeM has joined #arm-netbook
<libv>
techn__: drm driver to do what with?
<techn__>
libv: Currently it creates dummy bindings for /dev/fb and sysfs
ZaEarl has joined #arm-netbook
<libv>
techn__: and the goal is?
<techn__>
short term.. to get simple framebuffer which uses normal layer (no scaling) and hdmi
<techn__>
long term.. whole disp to mainline
<techn__>
but.. if someone wants to implement TCON0 and LCD, RGB or tvout for short term, its welcomed too :p
<libv>
it's the wrong approach
<libv>
one that leads to dumbing down of our userbase and the loss of register level information
<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
<hramrach>
how is register level information lost?
<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..
<libv>
nope
<hramrach>
no move if you just add kms glue on top
<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
<techn__>
and this current driver is suffering issues which comes free for drm/kms
<libv>
and there is little regression risk when cleaning/restructuring properly
<libv>
but that does require patience and clue
<techn__>
like improved page flipping and architecture for dual display
<libv>
for free?
<libv>
really?
<hramrach>
the architecture for dual display does not come out of nowhere
<libv>
you'll have to explain the mechanics of that "for free" to me then
<hramrach>
you still ahve to figure out how to configure it with the actual hardware
<libv>
techn__: in any case, if you want to do something useful, and want to play with kms
<libv>
try bolting kms on top of the current disp and try to sensibly restructure disp underneath it
<libv>
the approach you are taking now is just stupid, and will only lead to further stagnation
FergusL has left #arm-netbook ["Quit"]
<libv>
it is however something one thinks off on a sunday afternoon
eFfeM has quit [Quit: Leaving.]
<libv>
but believe me, there are much better things to do, which actually will help us along long and short term
<libv>
techn__: for an example of the sort of kamikaze stupidity you are running into: the openchrome driver
<techn__>
I just hate to see that if I do something for current module I have to do it again in future
<techn__>
libv: I understand that
<libv>
they forked away from me because i did not want to accept VBE based modesetting
<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
<libv>
nothing ever gets fixed.
<libv>
techn__: use your spare time/energy elsewhere then
sv has joined #arm-netbook
discopig has quit [Ping timeout: 276 seconds]
drgreenthumb has quit [Read error: Connection reset by peer]
sv is now known as discopig
rz2k has quit []
<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
<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?" :)
<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, ..."
<libv>
disp is a dead-end, it should die
<libv>
but it should die slowly, through dissection
<libv>
there is loads of very relevant information in there
<libv>
which we simply cannot afford to lose
<ssvb>
yes, exactly
<libv>
the way to do it is to restructure it, and then bolt something better on top
<libv>
not by starting afresh
<libv>
you get absolutely nothing for free when starting afresh
<libv>
and you throw out the baby with the bathwater while doing so
<libv>
and only then does the openchrome syndrome kick in
<anunnaki>
and when i get to Run the test program step. i typed qemu-arm ./hello i get "qemu-arm command not found"
<anunnaki>
i also tried qemu-armv4 ./hello as well.. same result
<anunnaki>
i also emerged qemu with the arm use flag.. no change in result
<libv>
hrm...
<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
<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?
<ssvb>
libv: the real problem is that libMali.so depends on ump
<libv>
ssvb: i am struggling with introducing versioning on the headers
<libv>
i haven't figured out what the best route is
<libv>
oh, that one is easy
<libv>
my current code just installs the r3 headers
<libv>
as there are no abi breakages in there
<libv>
there are only additions to the api
<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
<libv>
i am currently thinking about echoing a version into ump_version.h
<libv>
but this then requires proper dependency tracking when building libUMP.so