alcides has quit [Quit: Fighter by day, lover by night, drunkard by choice! Ready to fight!]
libv_ is now known as libv
<libv>
bsdfox, lundman: broadcom videocore has nothing to do with mali
<lundman>
hello captain obvious!
<lundman>
:)
<lundman>
guess i wasnt clear. They claim to be first to be open-source, and yet, it seems broadcom only released exactly the same amount that we have for mali
<lundman>
so, to me, it doesnt feel like they were they first, but rather, the last to join all the others
<libv>
bsdfox: bcm released code which just send opengles calls to the videocore dsp/gpu
<libv>
bsdfox: package it up, pipe it through the kernel, out to the rtos running on the videocore
<libv>
bsdfox: some people have rightfully stated "why didn't broadcom release this together with the kernel code and other rpi bits"
steev has joined #arm-netbook
Txl0591 has joined #arm-netbook
Txl0591 has left #arm-netbook [#arm-netbook]
gsilvis has joined #arm-netbook
tekzilla has quit [Ping timeout: 268 seconds]
tekzilla has joined #arm-netbook
carbont has joined #arm-netbook
carbont has quit [Client Quit]
slapin_nb has quit [Remote host closed the connection]
drachensun has quit [Quit: Leaving]
ZaEarl has joined #arm-netbook
ZaEarl_ has quit [Read error: Connection reset by peer]
cheng has joined #arm-netbook
<libv>
ooh!
<libv>
sunxi has big litter byte ordering!
tzafrir_laptop has joined #arm-netbook
mSquare has joined #arm-netbook
rellla has joined #arm-netbook
<libv>
yeggid
<libv>
#define __bool signed char
<libv>
massive abi break if i fix that :(
<lundman>
ugh
<libv>
is there anything that we know of that is using the disp ioctls?
<lundman>
android seems to after it boots
<libv>
ah, yes, crap.
<libv>
well, that depends... do you have gralloc or hwc modules for allwinner lying about?
<libv>
strings on them should give you /dev/disp if it is trying to do funky stuff
<lundman>
i dont at the moment
<libv>
ah, i found code
<rellla>
morning
<libv>
crap.crap.crap.
<libv>
on the other hand, hwc will use only a minimal subset
<rellla>
does anybody know, if r2p4-armhf libs are broken?
<rellla>
i get a: libEGL.so: undefined reference to `_mali_clz_lut'
<rellla>
can remember, somebody spoke about it already in irc
pwhalen has quit [Ping timeout: 244 seconds]
<rellla>
mnemoc: what kernel-branch is recommended for r3p0/r3p1-libs? stage/sunxi-3.0? what's 'mali'-difference to next_mali?
Quarx has joined #arm-netbook
pwhalen has joined #arm-netbook
<Gumboot>
Winmodems.
<Gumboot>
The opposite extreme; zero CPU offload, and widely hated for being cheap and crappy as well as for not providing drivers for anything but Windows.
<Gumboot>
I don't remember people slagging off the RS232 ones that came before.
<Gumboot>
And yes, they did have that problem of becoming obsolete stupidly quickly. I remember there were an awful lot of cheap project boxes which were simply recycled 9600 bps modems which had become obsolete before they cleared the shelves.
* Gumboot
goes to bed because it's 7:30am and that's where he should be.
<libv>
hrm... 46
<libv>
46 ioctls used by the aurora hw code
<libv>
abi for them should not change, better write some test code for that :(
<hno>
libv, you are trying to clean up disp ioctl structs/types?
<libv>
well, intending to
<libv>
without changing those there will be little real rewriting in the background
<libv>
so the users of disp need to be mapped out
<andoma>
mornin
tzafrir_laptop has quit [Ping timeout: 244 seconds]
<oliv3r>
lo
<mnemoc>
rellla: stage/sunxi-3.0 includes next_mali, but also other patches that need testing
mysteryname has joined #arm-netbook
<rellla>
mnemoc: then i'll give it a try - what's the recommended matching binary-libs for using fb? first i'd try those from github/linux-sunxi. i'm testing xbmc with armhf-cedars but i failed with the armhf-r2p4s with the mentioned error above.
<mnemoc>
rellla: fb doesn't need any lib. if using next_mali or the stage branches want r3p0 mali libs
<mnemoc>
iirc armhf r3p0 fb libs are untested, but the x11 ones are
deathz0r- has quit []
<rellla>
surely, i meant s/fb-libs/mali-libs/. so its time to test the untested.
<vanner>
which mali version tested with sunxi-3.0 branch for X11? i'm going to build one today
<vanner>
or which kernel branch and mali driver is simple to use for linux with x11?
pawel5870 has joined #arm-netbook
<mnemoc>
try the stage/sunxi-3.0 branch + r3p0 libs
<vanner>
thanks, i'll try it
<mnemoc>
rzk has some repos to compile the open source user space libs
DEAT has joined #arm-netbook
<vanner>
ok, thanks
mysteryname has quit [Ping timeout: 244 seconds]
DEAT has quit [Read error: Connection reset by peer]
<popolon>
looks like braodcomm changed a little :)
<RaYmAn>
only a day behind ;)
<popolon>
they have now the most opened ARM SoC
<RaYmAn>
it's arguable
<popolon>
why for ?
<mnemoc>
popolon: nope, the moved the private part within the "firmware" and open source an RPC client
<mnemoc>
not a driver
<popolon>
ah ok
<RaYmAn>
mnemoc: tbh, that's saying it wrong. They didn't move it into the firmware. It was always there
<mnemoc>
ah, ok
<RaYmAn>
As far as I can tell, it's not a malicious move that has been done now to avoid releasing source
<RaYmAn>
it was a technical design decision done early on
<mnemoc>
it's malicious to claim the SoC is open
<RaYmAn>
they claim the userspace is open
<RaYmAn>
:P
<mnemoc>
:)
<RaYmAn>
which is technically true
cat_x301 has quit [Ping timeout: 272 seconds]
<mnemoc>
so they basically "fixed" the closed libs in userspace nightmare without having to disclose anything about the GPU beside that is has a gl interface
cat_x301 has joined #arm-netbook
<mnemoc>
but still pissed by the deceiving way it was announced
<RaYmAn>
pretty much
<RaYmAn>
Gumboot: if you are in any way related to tegra then, Please, for the love of god, fix the reboot to recovery issue (Bootloader doesn't clean boot-to-recovery misc flag => brick if recovery is broken. Impossible to enter fastboot because flag takes priority and it's never cleared.
AndChat138129 has quit [Read error: Connection reset by peer]
AndChat138129 has joined #arm-netbook
<oliv3r>
full brick? or does FEL mode still work?
<RaYmAn>
(not a10 - nvidia tegra.)
* cat_x301
is going to give a try for stage/sunxi-3.0
<oliv3r>
stupid question, DirectFB, isn't that simply some 'form' of an 'Xserver'? to put it very very bluntly? I never quite understood what DirectFB waas, i thought at first it was a FB replacement or they where banging stuff directly onto the graphics card
<mnemoc>
it's an abstraction to use fb with hardware acceleration
<oliv3r>
but where does this hardware acceleration come from? I don't belive they write 'drivers' for all graphic chips?
<mnemoc>
they do :)
<oliv3r>
oh god, poor bastards :p
<mnemoc>
the a10's driver is hacked on top of vmware's
<oliv3r>
so to build, for example a htpc, you either use X or use directFB
<mnemoc>
using g2d/mp for hw acceleration
<mnemoc>
you can also use mali/fb libs
<mnemoc>
that is gl without x
<oliv3r>
so that's not-directFB
<oliv3r>
:p
<oliv3r>
or rather OpenGL -> Framebuffer
<oliv3r>
so what purpouse has directFB (on the graphics front) when you can do OpenGL -> Framebuffer
mysteryname has joined #arm-netbook
<mnemoc>
oliv3r: there are things that can be accelerated better in 2d than in 3d
<oliv3r>
for now, 2D 'hardware' is slowly dissapearing isn't it?
<oliv3r>
radeon's don't even have a 2D core anymore? I think the 3D engine handles it (though it may expose some 2D stuff still)
<oliv3r>
also with a lot of frontends (gnome, android?, xbmc etc) moving to 3D composed desktops, 2D will die at somepoint :)
<mnemoc>
the a13 doesn't have a 2d core. no idea about a10s or sun6i
<oliv3r>
a13 does have the mali core though, right?
<slapin>
mnemoc: There is currently no text in this page. You can search for this page title in other pages, or search the related logs, but you do not have permission to create this page.
<mnemoc>
slapin: of course, you haven't written it yet
<slapin>
mnemoc: ah, I see then
<Tomer>
rm, I bought an mk802 from amazon, it was working fine for a while, but since yesterday I plug it in the power and tv and the tv says "NO SIGNAL"
<mnemoc>
rip?
<Tomer>
I read online that I can try flashing the rom with LiveSuit and a specific image, tried it, it said it was done successfully and yet when I plug it into my tv there's no output
<Tomer>
the amazon page said it's MK802, and I see there's also a MK802-2 version (||), and theres another image for it, any chance it might work?
<Tomer>
how can I tell if its somehow "mk802 ||" and not just "mk802
<mnemoc>
the mk802 ii has different ports
<Tomer>
ah, full hdmi port, 3 usb ports, thats not what I got
<cat_x301>
mnemoc: hmm.. stage/sunxi-3.0 branch + r3p0 do no cope together, still getting unhandled ioctls.
mSquare has quit [Ping timeout: 246 seconds]
mSquare has joined #arm-netbook
<mnemoc>
cat_x301: never tried mali myself. I only merged next_mali which was *claimed* to be working
<cat_x301>
mnemoc: no worries.. i am really pissed-off that i still cannot get ui running reliably.. but who said that it is going to be easy, huh? ;)
<mnemoc>
easy = boring
<oliv3r>
i'm backreading the r-pi crapnnouncement on /. and notice someone in the comments mentioning 'the chinese promise that the A10 have an entire free stack'. Obviously the mali core can't be controlled by china nor Allwinner, but what exactly do these chinese 'promise'?
<oliv3r>
it is stated that obvvviously A10 hasn't delivered yet, all there is is a promise
<mnemoc>
the main difference is that you can use any A10 device without any bit of closed code
<mnemoc>
if you are willing to give up on 3d and hardware accelerated video decoding
<mnemoc>
the r-pi was not even been able to boot without the blob
<oliv3r>
49 USD board sold out :)
<mnemoc>
exceptable
<oliv3r>
r-pi is a piece of crap
<RaYmAn>
mnemoc: mm. So what you're saying is that if that code was in a bootrom it would be ok? :P
<oliv3r>
imo
<oliv3r>
the idea was really good
<oliv3r>
it's execution seriously flawed
<mnemoc>
RaYmAn: the bootrom is slim enough to not count :p
<oliv3r>
r-pie is only successful now because of it's hyping. i'm sure many are dissapointed
<oliv3r>
bootrom the 32k BROM?
<RaYmAn>
mnemoc: mm
<oliv3r>
i belive in richard stalmans words, that if it is true ROM, it is conciderd part of the hardware
<oliv3r>
if the BROM is flashable however, in any way whatsoever, it's firmware and needs to be set free :)
<mnemoc>
the BROM can be considered part of the hardware, yes
<RaYmAn>
that argument is kind of fail though
<mnemoc>
:)
<mnemoc>
the BROM only knows to poke around checking what's bootable, and to trigger (the also closed, but in true ROM) FEL
<mnemoc>
slim enough for me :)
<mnemoc>
RaYmAn: not for you?
<oliv3r>
FEL mode is also in ROM?
<RaYmAn>
mnemoc: I just think it's more of a gray area. Caring whether they put it on flash or on a microsd is rather irrelevant imo
<mnemoc>
RaYmAn: the BROM is not on flash, it's within the soc
<mnemoc>
oliv3r: yes
<RaYmAn>
The distinction seems rather irrelevant
<mnemoc>
RaYmAn: so you consider the slim brom of the a10 and the closed firmware of r-pi's (or tegra's) videocore to be ... equivalent in terms of the openness of a system?
<RaYmAn>
mnemoc: I consider the fact that the closed firmware encumbers much more of the system an issue wrt openness.
<RaYmAn>
I don't consider whether the firmware is on flash or ROM a considerable difference.
<oliv3r>
in the end, all firmware should be set free. In my opinion, it is still software. It is compiled code. And yes, in the ideal world, even your microwave or whatever device with whatever small piece of firmware, should be liberated.
<oliv3r>
I do find, for now anyway, the A10's BROM acceptable. It is small enough to not possibly cause problems for one.
<oliv3r>
the r-pi's firmware, is a huge blob, causing many problems
<RaYmAn>
definitely and *that's* exactly the issue.
<RaYmAn>
They could have put that huge blob on a ROM and according to your definition, it would suddenly be open.
<mnemoc>
that's why I used the term "slim" :<
<RaYmAn>
slim is rather vague
<ZaEarl>
if it's in a rom, and can't be changed, there's far less use in it being open.
<mnemoc>
problem is when they put a large and buggy pile of code in ROM to be "open"
<RaYmAn>
definitely
<mnemoc>
that's even worse than an upgradable firmware
<RaYmAn>
that was my primary point
<hno>
FSF seem to have changed their mind a bit on that when it comes to endorsable hardware.
<Gumboot>
RaYmAn: I do not know the issue. I could dig around, but it's a fair assumption that if I found it I could then not confirm or deny that I found it, let alone say anything about the outcome.
<hno>
Gumboot, tied hands?
<Gumboot>
I'm simply assuming that NDA would block me.
<hno>
tied hands.
<RaYmAn>
Gumboot: no worry - my point was rather to tell *someone* from nvidia :P It's a rather silly bug to have. I don't mind not hearing anything back ever.
<arnd>
I hope I can talk to some of the Mali folks next week during LinaroConnect, With the Broadcom VC4 "drivers" being open, we might be in a better position to ask for open user space for their stuff ;-)
<libv>
slapin: can you create a wiki page for the hyundai on linux-sunxi.org?
<mnemoc>
arnd: if arm/mali people can't see value in having real open mainlined drivers, we can't even dream about the rest understanding it :<
<libv>
:)
<Gumboot>
It's not about seeing the value in it. It's about the value in the opposite action being removed.
<libv>
guess why arm is not supporting lima or providing their own free driver?
<mnemoc>
$$
<arnd>
mnemoc: well, I'm sure they see value in it already, it's just that for them it's a tradeoff against the value in keeping it closed
<slapin>
libv: I don't really remember how to operate mediawiki, so I will try to figure it out tonight
<arnd>
If I want to play with a10, is dx.com/p/ak802-844145525 the right hardware to get?
<libv>
slapin: it is not too bad, but of course it is completely different than moinmoin wikis
<arnd>
I just saw that it has now appeared in the european store
<libv>
slapin: i am sure that if the developers were put in the same room, noone would come out alive
<mnemoc>
arnd: problem with those hdmi dongles is the access to the uart
<mnemoc>
arnd: but you can always get it out of the uSD pins
<hno>
arnd, doubt it's doable for ARM. Very different separation in IP boundaries, with most of the IP within the libraries and not so much the GPU/firmware.
<libv>
mnemoc: do you, with your allknowing mind, know of anything else that uses the disp engine besides the android hardware code for a10?
<libv>
hno: nope.
<arnd>
mnemoc: so I can't use uart and uSD at the same time then?
<mnemoc>
arnd: hno made some jtag based voodoo to have both... but it's evil
<libv>
hno: all i can find in the mali stuff is the algorithm for using the cache for the vertex shaders most efficiently
<mnemoc>
arnd: the simplest of all is to get a mele
<libv>
hno: and the compiler is cpu time optimised, not gpu efficiency
<hno>
libv, in the libs?
<mnemoc>
libv: ehm... don't know for sure... but adding some printk()s will tell :)
<libv>
mnemoc: well, strings | grep disp should reveal /dev/disp on some libs
<libv>
mnemoc: but nothing that you know of then
<mnemoc>
libv: not really into that part of the a10 world, sorry :<
<hno>
thought they had a bit more intelligence in there..
<libv>
hno: check my fosdem video
<libv>
here i describe the one thing that might be controversial, and how i get around it
<hno>
slapin, you also have serial and JTAG at the pads closer to the CPU. The topmost two is serial, and the four below the resistors are JTAG.
<libv>
and the thing is pretty meek indeed: the polygon blocks layout for optimal efficiency, we can easily benchmark our way out of that one
mnemoc has quit [Excess Flood]
mnemoc has joined #arm-netbook
<oliv3r>
arnd: just don't mention their 'open' stuff being steaming pile of useless crap :)
<oliv3r>
mnemoc: arm udnerstands, arm management, doesn't. Appearantly, even ARM engineers tell arm to let them OSS it as it will be most beneficial
<arnd>
oliv3r: it's not useless, it's just something else than what we would need from them
<libv>
hno: yes :)
<libv>
hno: as an added bonus, i aim will's laptops webcam at my gut for 10 minutes at the end :)
<arnd>
what broadcom has released is good for porting drivers to other operating systems or windowing systems, but it's useless for hacking on the driver itself
<hno>
Ok. Will listen on it carefully later today. At work doing other stuff at the moment.
<libv>
hno: i pretty much explained the one thing already though :)
<hno>
libv, possible, but not keeping up with the backlog here either at the moment. Mind on other high level C stuff.
<libv>
31 minutes in this video is where i talk about this
<oliv3r>
libv: the projectlaunch vid from lima earlier this year at fosdem?
<slapin>
libv: any links to video?
<libv>
oliv3r: yeah
pawel5870 has quit [Ping timeout: 276 seconds]
<libv>
slapin: the phoronix link has it
<mnemoc>
oliv3r: yes, i was refering to the "management". not the normal engs
<libv>
ok, so libcedarv/linux-armhf/sample/render talks to the disp engine, but in an even more limited way than android
<libv>
and we have source for that one :)
<mnemoc>
:)
<slapin>
do we have source for libcedarv?
<mnemoc>
no
<oliv3r>
nope
<mnemoc>
but we got armhf/neon libs yesterday
<oliv3r>
god that video is horrible. camera even falls
<libv>
nothing in the libs
ZaEarl has quit [Quit: Ex-Chat]
<oliv3r>
libv i think you said in the vid, that GPU drivers is keeping manufacturers back; is this still the case you think? (I would assume so) if so, why hasn't it still changed?
<libv>
device manufacturers, yes
Almamuetya has joined #arm-netbook
<libv>
why it hasn't changed, well, for many reasons.
<hno>
slapin, only partial source of non-important parts stolen from ffmpeg.
<libv>
the cost of open sourcing things is high, and this way the silicon vendor shifts some of this higher cost of integration to individual device makers
<libv>
and the device makers of course do not get organized, and demand, in concert, that this is relieved
<hno>
libv, they won't until they understand that they can expect better.
mysteryname has quit [Ping timeout: 244 seconds]
<libv>
well, nokia meego did, but that depended on the people in the organization
<oliv3r>
well someone needs to tell them properly :)
<libv>
i doubt that the bazillion chinese device makers understand it
<hno>
linaro also understands.
<oliv3r>
I'm supprised google hasn't stepped up and done anything in this regard, they should be fully aware of this
<libv>
hno: linaro is not a device manufacturer
<oliv3r>
samsung is beginning to understand I'd guess?
<libv>
hno: also, the stakeholders in linaro tend not to be device makers
<hno>
true, but many rely on them.
<hno>
but longer term, not per product.
<mnemoc>
linaro is probably the most frustrated group of all. having access to the people and the code and not been able to open source the stuff :<
<libv>
hno: so linaro is kind of preaching to the choir, but in the meantime giving the less clued-up manufacturers an easier time already
Tomer has quit [Ping timeout: 260 seconds]
<hno>
yes
<hno>
so three steps forward, 2.5 back.
<libv>
oliv3r: i fear that samsung might be like nokia in a few respects: apart from the fact that samsung actually is a viable company still today and actually manages to deliver what many customers want
<libv>
many different groups or factions in samsung will be pulling in different directions
<libv>
as is true for any big company
<oliv3r>
like nokia? gonna go in bed with MS only and become obsolete?
<oliv3r>
samsung has grown enormously in what, 30 years?
<rm>
don't forget that mobile is only part of Samsung
<rm>
unlike nokia
<oliv3r>
nokia used to make lots, including CRT's!
<andoma>
and tires and wellington boots
Almamuetya has quit [Ping timeout: 248 seconds]
Almamuetya has joined #arm-netbook
rsalveti has quit [Ping timeout: 244 seconds]
rsalveti has joined #arm-netbook
alcides has joined #arm-netbook
* Gumboot
shifts his opinions around some more.
<Gumboot>
I see these words on libreplanet.org: "the hardware must run free software on every layer that is user upgradeable"
<Gumboot>
Which I guess makes the difference between an RS232-based modem running locked-in as well as locked-down firmware, and any of the more modern devices which get their blobs uploaded from the kernel.
<libv>
so... android, some test code in cedarv, and the display poking bit of C that's floating around on the web talk to /dev/disp ioctls
<libv>
anyone have suggestions for where to look for further nasties?
Almamuetya2 has joined #arm-netbook
Almamuetya3 has joined #arm-netbook
Almamuetya has quit [Ping timeout: 244 seconds]
<Gumboot>
I tried to buy some Nokian tyres a couple of years back. Couldn't find a distributor, though.
<Gumboot>
Or maybe I couldn't find a tyre. They might have pulled out of the cycle tyre business.
<Gumboot>
No, looks like they're still doing them.
Almamuetya2 has quit [Ping timeout: 244 seconds]
<Gumboot>
Anyway, I do wonder about the merits of endorsing something just because its firmware is locked in. It makes sense for something like an external peripheral, but once you start talking about bus masters there are big questions about degrees of intrusion into the system and bugs and security and snooping.
<Gumboot>
Thunderbolt blurs that boundary even further.
<Gumboot>
I'd have thought drawing the line at some kind of standardised interface would be more fundamental.
<Gumboot>
But evidently not the OpenGLES interface.
<mnemoc>
libv: would be you move your work upon the stage/sunxi-3.0 branch? :)
<libv>
i probably should, yes
<mnemoc>
\o/
<libv>
but now things are not going to move as fast anymore... first need to write up some code to test /dev/disp interfaces and types, so i do not break the users too often :(
<mnemoc>
what about keeping /dev/disp for compatibility and adding a new interface in kms (or similar) fashion?
<libv>
mnemoc: starting from scratch is not too useful
<mnemoc>
ok
<libv>
mnemoc: i will rewrite the backend slowly, will add a disp ioctl versioning scheme, and will try to keep breakages limited
<mnemoc>
:)
<libv>
i never am one for throwing stuff away and starting from 0
<libv>
i have seen too much NIH in my time, and hit too often by it (randr1.2, kms, radeon, openchrome, ...)
<mnemoc>
i was thinking more in refactoring to let both interfaces share
<libv>
if and when possible
<mnemoc>
fair enough
<libv>
again, i will make sure that i do not accidentally break stuff, and will strive for maximum compat
<libv>
and check out my fosdem 2010 talk slides :)
<libv>
i built up radeonhd modesetting from scratch to be build-time compatible with suse enterprise and debian stable
<libv>
and i am/was the only one doing so
<libv>
until a few months before that slide, i was compatible with xfree86 4.3
<libv>
well, first i expose the innards in a sensible fashion, so that the actual bitbanging can be reused for kms
<libv>
but the drm concept is badly structured and broken anyway :)
<mnemoc>
:)
<libv>
having modesetting depend hard on a fully featured memory manager, and lumping everything, even 3d command queueing and some limited 2d accel together that badly is pretty unforgivable
<Gumboot>
What hardware are you talking about?
<libv>
working on sunxi disp atm
<libv>
but unichrome is the via igp
<Gumboot>
OK. It's just, I noticed in the rpi forum you mentioned your work on tegra. If that's on-topic in this channel then I'll have to leave.
<Gumboot>
I don't want to be a whiney bitch or anything... it's just ... you know ... not getting fired, and all that.
<libv>
Gumboot: someone else is working on tegra2 REing, someone who has been hanging around the lima channel for ages (but unable to directly contribute as he actually worked on the mali several years ago)
Almamuetya3 has quit [Ping timeout: 244 seconds]
<Gumboot>
<fingers-in-ears>lalalalalalalalalala!
<libv>
?
Almamuetya3 has joined #arm-netbook
<Gumboot>
I don't want to hear about reverse engineering work relating to my employer.
<RITRedbeard>
You work for Nvidia?
<RITRedbeard>
Tell them to quick sucking.
<RITRedbeard>
quit, rather.
<libv>
Gumboot: you do know that this channel is publically logged, right?
<Gumboot>
I think there's a diplomatic response to that, but I don't have the big book of party lines to hand.
<Gumboot>
libv: It's no secret where I work. I'm not hiding that.
<libv>
quite the opposite
<Gumboot>
My only concern is establishing that I'm not hanging out in a career-limiting channel.
<Gumboot>
Yes yes, I know. It's right there in the topic, I think. Although that bit doesn't fit on my screen.
<Gumboot>
Yeah. Right there in the topic.
<libv>
mnemoc: in any case, don't worry, if anyone is going to keep the actively used disp bits running for long, then it's me :)
Almamuetya3 has quit [Ping timeout: 244 seconds]
<mnemoc>
libv: :)
<libv>
btw, we might want to introduce a new ioctl
Almamuetya3 has joined #arm-netbook
<libv>
and allwinner has given us just what we need there: two reserved ioctls at the start of the table
<libv>
this new ioctl should be a versioning handshake
Almamuetya4 has joined #arm-netbook
<libv>
giving users of the disp ioctls to at least recognize and actively warn when they are running against an incompatible version (when one does happen), it's better to introduce this ioctl asap though
<libv>
s/to/a chance/
<ibot>
libv meant: giving users of the disp ioctls a chance at least recognize and actively warn when they are running against an incompatible version (when one does happen), it's better to introduce this ioctl asap though
Almamuetya3 has quit [Ping timeout: 244 seconds]
Almamuetya5 has joined #arm-netbook
<mnemoc>
libv: give me a commit and I add it now
Almamuetya4 has quit [Ping timeout: 255 seconds]
<mnemoc>
btw, I just added an entry message about the public logs.
<libv>
ok, and nice :)
<libv>
let me write it up and test it first :p
<mnemoc>
:)
gzamboni has quit [Ping timeout: 246 seconds]
pwhalen has quit [Quit: Leaving]
Almamuetya6 has joined #arm-netbook
pwhalen has joined #arm-netbook
Almamuetya5 has quit [Ping timeout: 240 seconds]
alcides has quit [Ping timeout: 244 seconds]
Almamuetya7 has joined #arm-netbook
Almamuetya6 has quit [Ping timeout: 244 seconds]
slash_random has joined #arm-netbook
gzamboni has joined #arm-netbook
AndChat138129 has quit [Read error: Connection reset by peer]
AndChat138129 has joined #arm-netbook
mSquare has left #arm-netbook [#arm-netbook]
Almamuetya7 has quit [Ping timeout: 244 seconds]
<libv>
hrm, how often is code that allwinner threw over the hedge going to be merged in that blatantly?
<libv>
if this is the norm, then there is no point in cleaning or restructuring
<mnemoc>
it's the first time. most of the a13-sdk stuff is in a separated branch
<libv>
and going forward?
<mnemoc>
not much
<libv>
because i will have to redo quite a lot of things, basically all sun4i/sun5i unification needs to be redone
<libv>
not much is not a satisfactory answer for me when it comes to blatantly merging raw allwinner code
<mnemoc>
it's not merged
drachensun has joined #arm-netbook
<mnemoc>
it was more of a panic
<mnemoc>
considering 4 flows of incompatibles patchsets
<mnemoc>
to the disp driver
<mnemoc>
as any cleanup needed to include the a13 code
<mnemoc>
the bulk disp changes from the a13-sdk can also be left to rot... or "for future reference" ... as after the cleanups refactoring they be probably impossible to merge at all
<mnemoc>
but they haven't been merged into either of the main branches, only stage... so can be taken out
<libv>
well, with my heightened temperature and runny face, i am not up for rebasing and redoing that stuff today
<mnemoc>
i think techn rebased at least part of your refactoring already
arokux has quit [Read error: Connection reset by peer]
arokux has joined #arm-netbook
<libv>
rebasing will not work
<mnemoc>
was fearing so
<libv>
unification of sun4i/5i needs to be done afresh
jelly has quit [Remote host closed the connection]
<mnemoc>
another way is to apply the sun5i changes on top of the already unified one
<libv>
how?
<libv>
again, unification needs to be done afresh
<mnemoc>
meh :(
<libv>
all the rest can be rebased and manually retouched, but unification needs to be thought through from the start again
<libv>
as sun4i and sun5i diverge _a_ _lot_ now
<libv>
heh
<libv>
in some cases, sun4i settings get merged in, so some of the unification becomes superfluous
<mnemoc>
:<
sspiff has quit [Ping timeout: 244 seconds]
sspiff has joined #arm-netbook
alcides has joined #arm-netbook
alcides has quit [Changing host]
alcides has joined #arm-netbook
<cat_x301>
libv: what branch you're planning to take as a base for your work?
<libv>
cat_x301: what do you mean, planning?
<cat_x301>
s/planning/taking :)
<cat_x301>
libv: ah, never mind, just noticed that discussion was about sunxi-3.0..
<mnemoc>
cat_x301: it also affects sunxi-3.4
<hno>
I wonder.. is there really any differences between sun4i and sun5i disp hardware?
<cat_x301>
mnemoc: yeah, i see.
ssspiff has joined #arm-netbook
arnd has quit [Ping timeout: 244 seconds]
sspiff has quit [Ping timeout: 265 seconds]
rellla has quit [Quit: rellla]
ssspiff has quit [Remote host closed the connection]
Brandon15811 is now known as Brandon158111
Brandon158111 is now known as Brandon15811
rellla has joined #arm-netbook
<drachensun>
rellla: have you tried to build xbmc for the new cedar hf libs?
<techn_>
mnemoc: I have terriple headache today.. so dunno if I can do the rebase
arnd has joined #arm-netbook
<techn_>
Tom has raised already 12k :)
<mnemoc>
techn_: it can't be rebased... unification needs to be redone entirely
<mnemoc>
techn_: hopefully libv will leave the anger caused by commit from the a13-sdk behind soon :)
<techn_>
atleast part of it is cherry-pickable
<techn_>
I think cherry-picking is the way
<techn_>
and commit's which doesn't fit must be redone
<mnemoc>
git show $hash | git apply -3 --ignore-white-space tends to work better than cherry-picking
<techn_>
I think cherry-pickin also has ignore white space option :/
<mnemoc>
-3 is the magic part
arnd has quit [Ping timeout: 245 seconds]
<techn_>
it's not documented .. what does it do?
<mnemoc>
3-way merge
<mnemoc>
it's smarter regarding file changes
<mnemoc>
and files moved
<libv>
it won't help for the unification, again, unification has to be pretty much redone
<libv>
there is too much actual logic involved
<mnemoc>
that was exactly my thought when getting the commit in the stage.... "now or never" :<
<mnemoc>
but not sure if the "never" is such a bad idea :<
<mnemoc>
sun5i's hdmi is for the A10s SoC, from which we don't have anywhere to test
<mnemoc>
yet
Brandon15811 is now known as Brandon158111
vinifr has joined #arm-netbook
<mnemoc>
s/from/for/
Brandon158111 is now known as Brandon15811
<vanner>
mnemoc, you recommended me try rzk's mali driver. how to it build for A10?
<mnemoc>
rzk: ----^
<rellla>
drachensun: i have built it with success. now i'm trying to get it on a sd-card. a little complicated with my windows/vmware/no native linux/samba/nfs-connection ;-(
<Maqs>
mnemoc: what were the results of your u-boot sf/hf tests? did it work without -msoft-float?
Quarx has quit []
<libv>
mnemoc: what do you mean with sun5i hdmi being for a10 soc?
<mnemoc>
libv: A10s != A10
tzafrir_laptop has quit [Ping timeout: 255 seconds]
<libv>
ah, ok, and i guess that there are no such devices out there yet?
<mnemoc>
libv: it's a sun5i SoC designed for hdmi dongles
empat0 has joined #arm-netbook
<mnemoc>
libv: right. Tsvetan (from olimex) was going to get some samples, but nothing yet
<mnemoc>
empat0: wb!
<libv>
i've seen a lot of tablets advertised as a13 with hdmi connectors, but i guess that they are just mislabeled
<Maqs>
empat0: :-) may i disturb you for a minute?
<mnemoc>
libv: the A10s and A13 have incompatible footprints, they can't share PCBs
<libv>
mnemoc: could these be external hdmi controllers?
<libv>
although, that would bump cost
<drachensun>
rellla: you built it in windows?
<libv>
way above a10
<mnemoc>
libv: or external hdmi controller or actually A10
<rellla>
in a virtual machine debian/unstable-amd64 cross-compile....... very strange for me :-)
<empat0>
hi! just to inform you that armhf cedarx seems to work same as amel version. mali r3p0 framebuffer seems also to be ok, at leat for xbmc.
<libv>
the costs makes it more likely an a10
<mnemoc>
empat0: great news!
* libv
his brain is becoming more and more mush and more and more leniant to redoing some unification
<rellla>
empat0: thanks for the changes at github, i can't wait to try
<mnemoc>
libv: mail sent
<libv>
?
<mnemoc>
"you got mail" (tm)
<libv>
ah, ok, will need a minute to hit
<libv>
aha, ta :)
<drachensun>
rellla: wow that does sound pretty tricky. I'm just trying to build on the device right now
tzafrir_laptop has joined #arm-netbook
<slapin>
libv: do you have vudeo of that presentation, where camera really shows what's on projector, and not some wall all the time? :)
<slapin>
s/vudeo/video
<empat0>
which kernel version should i use for mali r3p0? is wip/linux-sunxi-3.0/next_mali ok or is there a better version?
<libv>
slapin: for fosdem? no
<libv>
slapin: this was someone in the room with a usb attached camera
<libv>
slapin: in room for 80 people holding 120 at least
<mnemoc>
empat0: try stage/sunxi-3.0 please
<libv>
you can see the demos in a separate video, and you can get the slides as well, all from phoronix
<slapin>
libv: I see
<libv>
slapin: fosdem is a bit of a happy mess from time to time
<slapin>
libv: thanks
<libv>
and it really shows in videos like this
<libv>
which is why we get to examine will's ear for that long
<rellla>
drachensun: i did with the armel-version, but i'm sick of waiting 6h and then maybe start from the beginning... but my binary is not proofed yet. maybe i'll have to do it native again....
popolon has quit [Quit: Quitte]
gimli has joined #arm-netbook
arnd has joined #arm-netbook
arnd has quit [Ping timeout: 240 seconds]
<slapin>
libv: don't you have links for slides? I can't find any :(
AndChat138129 has quit [Ping timeout: 245 seconds]
<shivansps>
i have the linaro beta from j1nx working on my novo 7 aurora, i downloaded and compiled natively extra modules, like the one for the goodix ts, but i cant modprobe them because it says invalid format... it was compiled for the correct kernel version...
AndChat|138129 has quit [Ping timeout: 240 seconds]
AndChat138129 has joined #arm-netbook
<andoma>
so does anyone know anything about the flickering that seems to happen in 1080p60?
<andoma>
it seems to disappear in 1080p50 unless i turn on multiple layers, then it's back again
<andoma>
but if i drop to 1080p24 then it works with multiple layers as well
<andoma>
feels like the display output is unable to fetch data in sufficient speed or something
<shivansps>
looks like bandwidth issue to me
<shivansps>
what HDMI version is on the A10?
rellla has quit [Quit: rellla]
<slapin>
mnemoc: thanks!
<shivansps>
damn, depmod -av complains about missing variables for the new modules, i guess i need to compile and change the kernel as well?
<shivansps>
even if the same version
<slapin>
mnemoc: these are wrong slides, for xorg unification, there's no Mali stuff there...
<mnemoc>
ah, sorry. didn't know you were talking about that talk
<mnemoc>
slapin: matching version isn't enough. it needs to be the same tree and same config
<mnemoc>
or you'll miss symbols
AndChat138129 has quit [Ping timeout: 240 seconds]
AndChat|138129 has joined #arm-netbook
<libv>
andoma: the multiple layers thing indeed seems like a memory bandwidth issue
<andoma>
shivansps: HDMI version?
AndChat|138129 has quit [Ping timeout: 240 seconds]
tzafrir_laptop has quit [Ping timeout: 272 seconds]
<andoma>
libv: yeah hm . gonna play around a bit with it
<andoma>
maybe i can have my background layer in YUV color space to save some bw
<andoma>
see if that helps
<empat0>
andoma: you can try to get rid of it by using scalermode (just scale 1:1) instead of normal mode. this worked for me in xbmca10 (heavy gles+vpu+layer rendering)
<libv>
empat0,andoma: so you guys are playing with the display engine ioctls?
<libv>
where?
<andoma>
libv: yes
<empat0>
andoma: yes
<andoma>
empat0: ah interesting
<libv>
because i will need to make sure that the abis doe not change
<mnemoc>
empat0: what kind of ioctrl()s you use beside screen size?
<empat0>
layer request, layer configuration, video layer
<libv>
empat0: where is the code for this?
<shivansps>
nevermind, every HDMI revision should support 1080P@60hz... there is a bandwidth issue before reaching HDMI
<libv>
shivansps: reduced blanking does 1080p@60hz just fine
<libv>
(if you do not trust me, run info cvt, scroll to the bottom :))
<shivansps>
yeah but when something does not work at 60hz and it des work at i.e. 24hz sounds strange, it definitely not filling the framebuffer or the HDMI is not able to transmit it, i say that because ive see some flickering even at X11 desktop at 1080P 60hz
<shivansps>
its strange
<libv>
empat0: ok, cloning
<techn_>
mnemoc: Should I push libv's changes directly to stage branch?
AndChat138129 has joined #arm-netbook
<techn_>
shivansps: is it tearing or flickering?
<libv>
techn_: no, i would like to review things first.
<empat0>
mnemoc: stage/sunxi-3.0 also runs the framebuffer mali r3p0, even a little faster
<shivansps>
flickering, but i did not see it happening at the never kernel and mali drivers version
<shivansps>
at lest i did not notice it
<mnemoc>
techn_: once you are both happy with the changes, yes, you can push directly
<mnemoc>
empat0: little fast then?
<mnemoc>
than*
<mnemoc>
techn_: but maybe a wip can do better first?
<shivansps>
im now using my tablet screen, so no HDMI... not sure if its psible to use dual outputs
<shivansps>
thats seems to works only in androd
<Maqs>
empat0: what kind of a10 device do you have/use for testing?
<empat0>
Maqs: the plastic toy, mk802
<techn_>
mnemoc: libv.. I wont push those code relocations yet.. but first 4 commits which doesn't have any real code changes
<libv>
i think you mean 3, as the fourth is already done in stage
<techn_>
4th has some improvements over that
<Maqs>
empat0: ah, okay. me too. which u-boot/kernel? i'm had some problems with newer kernels + xbmca10, crashing after starting xbmc with hardware decoding
<Maqs>
therefore i wonder
<empat0>
mnemoc: i estimate 10% faster than the wip/next_mali kernel
<mnemoc>
oh
<Maqs>
s/i'm/i/
<techn_>
empat0: mnemoc: root cause for that could be "CSC improvements"
<shivansps>
oh this is just great, xbmc now fails sqlite3 check and the dev lib IS installed... man i hate when those things happen
<mnemoc>
techn_: nice :)
<empat0>
Maqs: is started with lubuntu, bootloader still from there, and upgraded kernel to 3.0.42
<empat0>
Maqs: miniand lubuntu
<empat0>
shivansps: look at config.log, sure another lib missing
<mnemoc>
Maqs: btw, did you have the chance to test your mm/bootmem.c crash with recent sunxi u-boot and the patch with printk()s I gave you?
<mnemoc>
Maqs: or with mali disabled?
slash_random has quit [Ping timeout: 240 seconds]
<Maqs>
mnemoc: didn't get back to my mk802 until this afternoon, so not yet. could you give me the patch again? i don't seem to have it in my backlog
AndChat138129 has quit [Ping timeout: 240 seconds]
eFfeM has joined #arm-netbook
<libv>
techn_: i did
<libv>
techn_: as i did not know any better, feel free to correct this
<mnemoc>
libv: and boots fine?
<techn_>
hno: could you fix that? also there is something broken with Makefiles.. it always does rebuild
<libv>
the sd card is not very reliable, but apart from that it works
<mnemoc>
Maqs: ----^
eebrah has joined #arm-netbook
<Maqs>
k, thanks.. that's about what i did
<mnemoc>
Maqs: and a ticket on u-boot-sunxi's issue tracker? :)
eebrah has quit [Client Quit]
<Maqs>
nope, no ticket
vinifr has quit [Ping timeout: 245 seconds]
<Maqs>
are there any kernel changes since 3.0.26 that make a newer u-boot necessary? i'm just asking because.. never touch a running system :-)
<Maqs>
interrupting u-boot and changing the configuration from command line is easier than taking the uSD out, putting it in an adapter, in the laptop, replacing a non-working u-boot and try again
<mnemoc>
Maqs: u-boot needs to pass proper atag mem and proper machine type. older versions of u-boot didn't do it. older versions of the kernel didn't need it
empat0 has quit [Read error: Connection reset by peer]
eFfeM has quit [Quit: Leaving.]
<techn_>
hno: could there be some check before touching that file :/
<hno>
shouldn't be very hard to rewrite the u-boot build system to not rewrite the file if there is no change.
<mnemoc>
techn_: [ -s ..../config.h ] || make ... ?
<mnemoc>
techn_: some for the kernel, one (optional) make to configure, another to do the build
<hno>
mnemoc, only if you know it's configured for the same board, and that boards.cfg have not changed for that board.
<techn_>
mnemoc: I think sunxi-bsp is wrong place to fix that problem
<mnemoc>
hno: yes, we are using O= to have one dir per config already
<hno>
techn_, so is sunxi u-boot.
<mnemoc>
techn_: i don't think it's good to overwrite the config every time.... we are better doing two calls
<mnemoc>
techn_: in the case of the kernel we will be destroying their .config tweaks
<hno>
?
<mnemoc>
running defconfig on every `make linux`
<techn_>
makefile system should keep track if something has changed.. but sure it can be worked around
<mnemoc>
defconfig forces an overwrite
<techn_>
mnemoc: that's true
<mnemoc>
same as u-boot's make $myboard
<hno>
just as u-boot make boardname does.
<mnemoc>
:)
freakazoid0223 has joined #arm-netbook
<techn_>
Ok.. lets fix sunxi-bsp then :)
<mnemoc>
so that one should run only once
<mnemoc>
:)
<traeak>
what happened to the lima driver, btw?
<hno>
once per what?
<hno>
defconfig will change. u-boot boards.cfg will change.
<hno>
traeak, what driver? It it a reing project.
<mnemoc>
hno: once between the first `make linux` and `make clean`
<Maqs>
mnemoc: make uImage -C kernel_path/ won't work any more, as it will look for "drivers/gpu/mali/mali/arch/config.h"
<mnemoc>
Maqs: ticket please
tzafrir_laptop has joined #arm-netbook
AndChat138129 has quit [Ping timeout: 240 seconds]
<hno>
mnemoc, why do you make clean?
<mnemoc>
hno: we don't. i'm just telling to not force as re-config as long as a config is there
<mnemoc>
in the hypotheical case someone wants to start from scratch a `make clean` could be done.... but as O= is used, that is basically a single rm -rf
<libv>
techn_: Conflicts kept in the message?
<techn_>
libv: yes
<mnemoc>
is that considered good practice?
<mnemoc>
I always remove them...
<mnemoc>
Maqs: thanks
<libv>
conflicts from where, what information does it add to rebased or cherry-picked code?
<Maqs>
you're welcome
<Maqs>
kernel is building again now :-)
<libv>
also. --author
<hno>
mnemoc, so build will fail to pick upp defconfig changes on source updates.
<mnemoc>
hno: i find it quite evil to assume you want a full reconfig every time
<mnemoc>
at least for the kernel further `make` calls will update .config (and ask)
<mnemoc>
but from there to force a defconfig...
<hno>
mnemoc, fair.
<hno>
assuming this is a script used by humans and not in an automated build procedure.
<mnemoc>
< /dev/null solves that iirc
<mnemoc>
at least in the kernel case
<hno>
?
<mnemoc>
taking defaults without the need of hitting enter
<mnemoc>
for the automated build procedure
<mnemoc>
but maybe in that case a `make clean` is better.... or not?
<hno>
mnemoc, make oldconfig do not pick up defconfig changes. Not even defconfig additions. Only defaults specified in Kconfig files. To pick up defconfig changes a make defconfig is needed.
<hno>
Maqs, Hmm...
<techn_>
mnemoc: pushing configure target
<hno>
techn_, if you are annoyed by uboot defconfiging itself on make boardname then this fixes it: http://fpaste.org/njJx/
<techn_>
hno: cool :)
<Maqs>
wow, nice
<Maqs>
mnemoc: solved the problem. i just compiled u-boot for the cubieboard. dram.c was identical for mk802.
<Marex>
slapin: hey, going to ELCE ?
<Marex>
anyone else going to ELCE here ?
<Marex>
hno: hey ;-)
<hno>
Hi Marex
<Marex>
hno: I heard Stefan got involved in A10 stuff ... looks like you now have quite a lot of core uboot people involved
<techn_>
mnemoc: pushed
<hno>
Yes.. not just need to shuffle the stuff into a form that can be digested on the ml..
<Maqs>
i wouldn't have noticed, but for compiling xbmc it is surprisingly cold :-)
<drachensun>
the last pin, square solder mask was tx
<techn_>
10 years ago.. when I last time used it.. there was only poor clones and really expensive orginal ones
rellla has joined #arm-netbook
<drachensun>
and it looked like the far 2 from it were ground, and I was getting output
<drachensun>
I soldered the wires on and tried again and it wont boot or do anything now
<L84Supper>
drachensun, did yours come with a choice of Chinese or Japanese Android?
<drachensun>
when I first ran it, it was already set for english
<mnemoc>
L84Supper: close tto 0.1" sounds more like 2mm
<L84Supper>
drachensun, I took it apart but never probed it for anything
<L84Supper>
mnemoc, yes 0.1" is close to 2mm and even closer to 2.54mm :)
<drachensun>
I'll let you know if I manage to figure out the pinout and get the parameters off it
<mnemoc>
L84Supper: I only mean to say that if 0.1" doesn't fit, it might be 2mm instead
<drachensun>
I have another, so I can try again but I was just really suprised it was fried, I can't figure out why
<L84Supper>
mnemoc, just kidding
<L84Supper>
drachensun, solder bridge maybe? hope you didn't zap it with some ESD
<mnemoc>
wow, the cubieboard campaign already reached 30% and he hasn't mailed the people on the notify me list yet
user__ has joined #arm-netbook
<L84Supper>
mnemoc, unlike some other people in here that shall remain nameless, I can actually read mechanical drawings :)
<mnemoc>
L84Supper: :D
user__ is now known as debianin
<L84Supper>
did Tom clear up his registration? I hope he'll actually get the kickstarter funds
<debianin>
hi all. hi mnemoc :)
<drachensun>
I did bridge two of the pins briefly in soldering, I'm still lousy with lead free solder, but they both showed as ground. I should have just clipped the damn battery before I worked on it
popolon has joined #arm-netbook
<mnemoc>
L84Supper: he sent all the papers paypal requested this morning. but until he went to sleep like 2h ago it was still blocked
<L84Supper>
ah ok
rellla has quit [Quit: rellla]
<drachensun>
well this A13 seems to have all the ram parameters in its bin file, so thats good maybe I dont need a header after all
<drachensun>
L84Supper: Have you used adb with the netbook?
<mnemoc>
drachensun: fexc -I bin -I uboot script.bin > dram.c
<mnemoc>
err
<mnemoc>
-O uboot
<L84Supper>
drachensun, I have only power it on and off, taken it apart for pictures and contemplated it's from of destruction :)
<drachensun>
lol
<L84Supper>
from / form
<drachensun>
its got no micro/mini usb so I'm not sure how I'm going to adb to run
<drachensun>
I guess I can just download the terminal app and work that way
<L84Supper>
I'm much more interested in the ARM Chromebook and possibly expanding it's emmc to 60x the size
<drachensun>
mnemoc: I'm just sure what you mean, where do I need to run that?
<mnemoc>
drachensun: fexc lives in the same dir as bin2fex/fex2bin
<mnemoc>
debianin: it's their ... backend
<mnemoc>
err
<drachensun>
ok, I thought so, I'm getting invalid out format -- "uboot"
<mnemoc>
i should readlly stop typing and go to take a nap :|