domidumont has quit [Remote host closed the connection]
domidumont has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
<Wizzup>
wens, ssvb: thanks, I managed to get the lime to go into host mode now, set kernel role to host, removed the pin detect for vbus and id from the dts, and set the dr_mode to host
domidumont has joined #linux-sunxi
Net147 has quit [Ping timeout: 246 seconds]
<wens>
Wizzup: congrats
ricardocrudo has quit [Ping timeout: 246 seconds]
CivilizedCoder is now known as tomboy64
Net147 has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
naobsd has quit [Quit: naobsd]
avph has joined #linux-sunxi
Net147 has quit [Ping timeout: 256 seconds]
Net147 has joined #linux-sunxi
Net147 has quit [Ping timeout: 265 seconds]
Net147 has joined #linux-sunxi
naobsd has joined #linux-sunxi
naobsd has quit [Client Quit]
enrico_ has joined #linux-sunxi
domidumont has quit [Quit: Leaving.]
domidumont has joined #linux-sunxi
cubietruck_user has quit [Ping timeout: 246 seconds]
khuey_ has joined #linux-sunxi
khuey has quit [Ping timeout: 246 seconds]
Net147 has quit [Ping timeout: 264 seconds]
bmeneg has joined #linux-sunxi
Net147 has joined #linux-sunxi
vishnup has joined #linux-sunxi
FR^2 has joined #linux-sunxi
ssvb has quit [Ping timeout: 246 seconds]
<topi`>
hi, what's the best way to playback video with mplayer? Is the GLES backend usable? I guess that just uses YUV textures for video display and the actual h.264 decoding is still done on the CPU.
<topi`>
and, is there already some mainline support for the H3? I've been thinking of getting those Orange Pi's
Gerwin_J has joined #linux-sunxi
<libv>
i personally steer clear of $shit_pis
<libv>
there are other h3 devices out there
<libv>
anything ending in _pi is a huge rip-off trying to cash in badly on rpi, by producing cheap hw and at best, copying linux-sunxi wiki with the promise of a community that never does exist
<libv>
and in the end, we get the clueless users asking clueless questions in here
arossdotme-planb has quit [Ping timeout: 256 seconds]
<grugly>
:)
<grugly>
libv: you get the same kinda thing with the boards ending in "pro"
FR^2 has left #linux-sunxi ["Connection reset by peer"]
<libv>
grugly: i cannot recall a sunxi based board with a name ending in pro that isn't already a $shit_pi
<plaes>
1. Pi, 2. Pro, 3. ... Profit?
<libv>
banana pi pro would then be scam² :)
<plaes>
there's at least one Pi Plus
<plaes>
and also Pi 2
<plaes>
Xunlong
<libv>
i am amazed that people keep on falling for that nonsense (like i am amazed that people still keep on sponsoring kickstarter marketing campaigns)
<plaes>
masses are stupid
<libv>
but what really pisses me off is that renowned computer magazines actually recommend these obvious ripoffs
<libv>
like C't
FDCX_ has joined #linux-sunxi
<jelle>
but I think the banana pi is mainline supported in debian though ;)
<jelle>
except OTG, but that should be an easy dts fix
<Wizzup>
in 4.3-rc1 perhaps
<libv>
jelle: no thanks to either lemaker or sinovoip
<jelle>
libv: o?
<jelle>
oh the company that makes them
<libv>
the companies that make them
<libv>
and who had a bit of a trademark (hah!) dispute from Q4 '14 on
<libv>
pretty surreal stuff
<jelle>
hmm they did fork linux-sunxi
<mripard>
libv: we can say that for pretty much every board we support but olimex and cubie's
<libv>
mripard: indeed, but the $shit_pi boards feign support
<libv>
and the later cubies are not better either
Ntemis has joined #linux-sunxi
<jelle>
well someone needs to educate them I guess, but there is a large barrier regarding culture
<mripard>
libv: well, it depends, one of the bananapi's company at least try
<libv>
jelle: i am sure that they are all very well aware of what they are doing
<jelle>
libv: I don't have a clue
<libv>
mripard: lemaker is supposedly better than sinovoip, but do you have any concrete examples of them trying?
<mripard>
I don't remember which one had a release based on top of mainline
<mripard>
with only some DT modifications
<plaes>
mripard: I tried setting up the audio stuff with your latest patches, (just used basic example in the devicetree doc)
<mripard>
maybe I've been a bit too eagirly cleaning up, and didn't notice this
<mripard>
the audio works ?
<plaes>
yes, speakers work
<plaes>
have to figure out the headphone connector
<plaes>
ok, only single extra line is printed: "Codec <-> 1c22c00.codec mapping ok"
<plaes>
and then the widget sink widget messages and route failures
<plaes>
this is Gemei G9 tablet
jjardon has quit [Read error: No route to host]
jjardon has joined #linux-sunxi
<plaes>
it even mutes the speakers when I plug in the headphone jack
<plaes>
but headphones are silent
arossdotme has joined #linux-sunxi
<plaes>
quite probably due to missing route in DT
<plaes>
mripard: do you need any other infor from me?
<plaes>
btw, the revision in /proc/cpuinfo is 0000
<grugly>
libv: I plan on buying more and using this one for something else, web server perhaps, because of the lemaker issues. What is a good board, do you think, for my minimal desktop project?
afaerber__ has quit [Quit: Verlassend]
cubeast has quit [Quit: Leaving]
<libv>
grugly: active and well known sunxi community members are on a "just ask" basis with olimex
nashpa has joined #linux-sunxi
<speakman>
Hi folks. Any idea why the sunxi Mali drivers lacks the fbdev_window.h ?
<speakman>
libv: I believe you are involved with the Mali drivers..?
<libv>
speakman: yes, but it's been 1.5-2ys since i last touched that repo
<mripard>
plaes: yeah, but my point is that it cannot even detect that the headphone has been plugged in.
<libv>
they should not be including such a headerfile.
<speakman>
libv: :D
<libv>
go complain there
<libv>
if they keep on complaining, send them to me.
<libv>
s/on complaining/talking bs/
<speakman>
libv: I've been discussing with the Qt devs as well. If I can find a better way to detect Mali in a proper way, they can probably apply a patch for it. Can you please help me find out The Proper Way?
<libv>
which "Qt devs"
<speakman>
I THINK (think!) they have just taken the first working way. Not a very though through way.
<speakman>
libv: #qt-labs
<speakman>
As I said; they're open for changes. If we can only find a more proper way which also works for other Mali repos than sunxi.
<libv>
speakman: they are working against other mali repos than sunxi
<libv>
and they could work around this easily in their .pro file
<libv>
without depending on an ARM proprietary header file which taints their whole product.
Igorpec3 has quit [Ping timeout: 264 seconds]
<speakman>
libv: If you can just give me a little hint on how to find the proper header file in the .pro file, I can create the patch needed-.
<libv>
speakman: sunxi-mali installs either the X11 or fbdev platform header depending on what the user wants to have installed
<libv>
and it automatically gets included by the standard egl headers
<libv>
Qt only needs this bs workaround for bs direct ARM deliveries
<libv>
so they need to check for the existence of this badly licensed ARM file in includedir/EGL/, and if so, include it, otherwise they should just use whatever egl.h provides
<libv>
and they should never use such a type directly
<speakman>
libv: Not sure how well you know about low level Qt (especially recent versions which has new ways of handling eglfs platforms), but first there is a "auto detect script" which runs from the configure script. That's where the right eglfs platform are supposed to be detected and will configure Qt to build that right module. In this case, the "config.tests"-binary can not be built due to the missing pr
<libv>
speakman: why can they not test for the existence of a file, or... cleanly handle the failure of this build?
gzamboni has joined #linux-sunxi
<speakman>
libv: I can try to figure out what is really required from the propritary file. I actually don't think it is required at all, but I need to refresh my knowledge.
gzamboni has quit [Ping timeout: 240 seconds]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
arossdotme has quit [Ping timeout: 256 seconds]
lemonzest has quit [Ping timeout: 246 seconds]
lemonzest has joined #linux-sunxi
lemonzest has quit [Read error: Connection reset by peer]
gzamboni has joined #linux-sunxi
paulk-collins has joined #linux-sunxi
arossdotme has joined #linux-sunxi
Igorpec3 has joined #linux-sunxi
mibofra has joined #linux-sunxi
<mibofra>
hi! I don't know if someone remember me from yesterday. Anyway I've found something interesting. "module ABI major version (15) doesn't match the server's version (19)" (from xorg logs). So into the 14.04 linaro imagines of the cubieboard 4 (allwinner a80), the 3D accel works because on the kernel tree there is the ddk, but the closed module (pvr_drv.so) is compiled for xorg with abi 15 (the version on ubuntu precise) and I've created an
<mibofra>
image of ubuntu 15.04 (with xorg abi 19). So is someone interested in reverse engineering the driver to create a open source counterpart?
reinforce has quit [Quit: Leaving.]
f15h has joined #linux-sunxi
fredy has quit [Excess Flood]
swiftgeek has joined #linux-sunxi
fredy has joined #linux-sunxi
viccuad has joined #linux-sunxi
lemonzest has joined #linux-sunxi
<libv>
mibofra: you want someone interested in reverse engineering an xorg driver?
<libv>
mibofra: do you want me to write you a quote in hours times my hourly rate?
<libv>
mibofra: you will have to provide me with full billing details such as name, address and VAT id.
<mibofra>
it's only a question dude, from a point someone has to start, and I'm not asking you, I'm only asking if someone is interested.
<mibofra>
calm down
<libv>
or perhaps you should not phrasing your request for help like that
<libv>
+be
ssvb has joined #linux-sunxi
<mibofra>
I've written if someone it's interested, nothing else
<swiftgeek>
or perhaps i should see lima work -.-
<mibofra>
don't be rude
<libv>
swiftgeek: first off, this is pvr, secondly, you do not want to know how many hours of my life i have burned on lima already
<swiftgeek>
i know ;D
<mibofra>
lima are the mali open ones if I remember correct
<swiftgeek>
but no peeking
<swiftgeek>
:D
<mibofra>
anyway libv I'm not asking you in particular, everyone can have a bad day or be so busy to be irascibile, it's comprehensible, but calm down
<mibofra>
lol
<libv>
mibofra: nobody is interested in reverse engineering anything, it's a massive timesink and never a preferred option for anything, it is a last resort only
<libv>
the way you phrased your question tells anyone reading it that you left out a bit of information already
<swiftgeek>
mibofra: people wen't to nut house after trying to reverse pvr, remember that
<mibofra>
ok I agree
<swiftgeek>
libv: quit being so offended -.-, or at least you appear as such
<libv>
swiftgeek: he is asking about the xorg module, not the whole gles stack
<swiftgeek>
then it's xorg
<swiftgeek>
and it may happen to some
<mibofra>
so apart from asking the cubieboard guys (trying to) provide the library compiled for xorg with abi 19, do you have other ideas?
<libv>
so it is not exposed to microcode/kernel/userspace interaction madness that is pvr
<libv>
mibofra: use an older xorg version?
<mibofra>
libv, not specifically xorg, it's the first thing I've thought about (because there is the driver). And using an older version it's the solution, I've thought about it, but I hope in avoid that option
<mibofra>
but thanks anyway
<libv>
abi version 15 versus 19 and pvr_drv.so, that's definitely an X driver
<libv>
so downgrade your distribution to an xorg server with abi 15, or ask the cubieboard people to get with the times (it seems that their standards have really slipped very far down now that benn and tom are gone)
<ssvb>
speakman: well, the presence of "/dev/mali" does not mean that we have mali400, so some improvements may be required
<mibofra>
libv, I've created the image and the rootfs to be upgrated lol, as I've said I hope if I ask the compiled module for abi 19 in an answer
<mibofra>
otherwise, I'll remain with the fbturbo and bye bye 3D accel until the upgrade of someone (cubitech guys or else)
<mibofra>
or me working on the driver for the powervr rogue
<mibofra>
who knows
<ssvb>
speakman: but all that the fbdev_window.h header provides is just the trivial "static mali400_native_window_t mali400_native_window = { 0, 0 };" part
<ssvb>
mibofra: if you have your ddx driver as a pre-compiled blob, then the best course of action is probably to use a matching version of xorg server
<mibofra>
ssvb, and maybe the only one, but trying to ask in a updated lib isn't killing anyone.
<mibofra>
anyway thanks for the advices, even if are obvious
<mibofra>
and libv stay calm lol
<swiftgeek>
libv: you are too far away to get a cookie
<ssvb>
mibofra: yes, you can ask cubietech for an updated ddx blob, or alternatively ask them to open source this code
<libv>
i am actually quite calm, i am just answering tersely
<ssvb>
mibofra: nobody in this irc channel can provide you with better blobs, because we are not representing any corporate entity (cubietech, allwinner or arm)
<mibofra>
ssvb, I was thinking of asking opening the code, but I think it's not possible for them (or it's allwinner code asked from cubitech buys).
<swiftgeek>
ssvb: there is always /query and magic things are happening from time to time ;)
<mibofra>
ssvb, in fact the question was if someone was interested in at the start.
<mibofra>
but probably I'll ask cubitech, at least for the upgraded lib.
<ssvb>
mibofra: well, the pvr based allwinner chips don't seem to be very popular among users
<mibofra>
and the a80 it's really recent in terms of sw developing, I know
<mibofra>
but someone can ask, no :D ?
<swiftgeek>
pvr + reverse is usually no
<mibofra>
anyway if I'll get the gpu accel in a way or another, I'll let you know guys
<libv>
seems like i was pretty succesful in scaring people away from pvr :)
<mibofra>
and the support on mainline (4.2) it's just started
<libv>
although, the mummy did most of the work
<swiftgeek>
libv: not really, there were people in the past
<swiftgeek>
few of them
<libv>
lkcl did some work on it
<swiftgeek>
since they stopped being active after that it looks really scary :D
<libv>
anything else was not really too serious
<mibofra>
the fact is that the cubieboard 4 it's a good board, really in the new image I've all working except from the powervr (using the 3.4 provided by the cc-a80 sources)
<swiftgeek>
and damn blob was always so buggy that this (myth) fits so well :>
<swiftgeek>
nvidia at least works with blob
<ssvb>
mibofra: honestly, the exynos based alternatives (odroid) look a lot more attractive to me than allwinner a80
<wens>
ssvb: i updated my primo81 to the latest firmware, though i haven't seen the wifi problems you mentioned
<libv>
swiftgeek: where do you have that information from?
<swiftgeek>
i don't know anymore :>
<ssvb>
mibofra: if a80 had sata, then that would be a completely different story
<mibofra>
I had to create a new image because even if linaro (ubuntu) 14.04 is an lts, is't too old for me, so I've made a ubuntu mate rootfs and put it into the image
<ssvb>
wens: wifi problems?
<ssvb>
wens: wifi works just fine for me
<wens>
ssvb: iirc you said that it stops working after it goes to sleep
<swiftgeek>
libv: as i said everything like that sticks so well with pvr hw, just because of quality of the blob if not for any other reason
<ssvb>
wens: ah, you mean the loss of connection after wakeup in android?
arossdotme has quit [Ping timeout: 256 seconds]
<wens>
ssvb: yeah
<wens>
by firmware i meant android
<wens>
the old stock firmware is useless with only 1g for apps...
<libv>
swiftgeek: the quality of what blob?
<ssvb>
wens: maybe that's somehow related to my wifi access point
<mibofra>
ssvb, really I was between the odroid and the cubieboard, both the octacore ones. The cubieboard have wifi and other things onboard so I was attracted by the cubieboard xD
<mibofra>
but I didn't put into the account the better support for the mail gpus
<swiftgeek>
so if you find interesting platform with (lots of) PCIe that isn't arm or x86 ... and if you like soldering
<swiftgeek>
you gonna have fun time with amd devs
<libv>
anyway, pvr had the most hope for getting direct support, but this was brushed from the table a few months ago
<libv>
probably by someone who goes golfing with my good friend at arm ;p
arossdotme has joined #linux-sunxi
<swiftgeek>
meh i want to hear more about lima :P
dev1990 has joined #linux-sunxi
<libv>
my last blog entry still applies
camh has quit [Ping timeout: 244 seconds]
<ssvb>
mibofra: what kind of 3d applications do you intend to run on your cubieboard4?
<swiftgeek>
which is kinda overreacting
camh has joined #linux-sunxi
<swiftgeek>
do you want huge cake for releasing nasty code?
<libv>
?
<swiftgeek>
if you claim nasty code as the good code people will get mad, and only that way
<swiftgeek>
otherwise trolls
<swiftgeek>
or not serious
<libv>
...
<swiftgeek>
and as for first option - what will give you the mood except of piles of cash
<libv>
that did not parse
<mibofra>
ssvb, really it's because I think if I've a piece of hw I've the right to have it working in every part of it, independently from the OS I run on that machine. Secondly now I'm talking about xorg, but really I want to try to put wayland with plasma mobile in top of egles
<libv>
swiftgeek: part of me is currently quite fed up with people expecting everything just because you did "something" (which in this case was quite a lot)
<swiftgeek>
libv: you live only ~100 years max
<libv>
swiftgeek: and you are not exactly helping there atm
<libv>
swiftgeek: yes, and i do not wish to spend most of that time living under a bridge just so i can meet your selfish expectations
<swiftgeek>
so you did something so great that it's the end of the story?
<swiftgeek>
or some health issues?
<libv>
?
<swiftgeek>
if you only want some figure there is always crowdfunding and at most it will fail
<libv>
i did singlehandedly start the whole open arm gpu movement, before me people either whined or just talked big without putting any effort behind it
<libv>
and it is amazing how much crap i do get for that
<swiftgeek>
because there are other issues
<libv>
mostly by people who have contributed amazingly little themselves
<swiftgeek>
namely with qualcomm as it's hw is at least consistent
<swiftgeek>
*its
<swiftgeek>
it's surprising to see somebody starting from the gpu
<libv>
swiftgeek: do you know where the term modesetting comes from? how that came into existence?
<libv>
do you know the story behind the liberation of ati?
<swiftgeek>
do you realize that we can't boot stuff anymore
<swiftgeek>
i just hope that after i manage to do it, qualcomm won't seal it forever
<libv>
swiftgeek: you really seem to be lacking a lot of background to this and the pvr story
<libv>
and i am now starting to loose my cool.
<swiftgeek>
don't please,
<swiftgeek>
all i'm saying that open-gpu isn't the only front that needs to be liberated
<libv>
swiftgeek: that statement tells me, once again, that you never properly read up on any of my public statements about opening up the mali
<swiftgeek>
what?
<swiftgeek>
i'm just saying that it's 2015
<swiftgeek>
and things with booting freedom went completely backwards
<swiftgeek>
and from my perspective i only see people giving up
<swiftgeek>
including myself
viccuad has quit [Quit: WeeChat 1.1.1]
<ssvb>
swiftgeek: you do have booting freedom with the current (past?) generation of allwinner hardware, that's why we all are here :)
<swiftgeek>
find a modem that gives you that freedom :P
<swiftgeek>
(fcc rules are crazy)
<ssvb>
just connect this modem via usb?
<ssvb>
and then we don't really care what kind of firmware it is running
<swiftgeek>
just load blob of gpu? :P
<ssvb>
you don't really see the difference, do you?
<swiftgeek>
sigh
<swiftgeek>
i should write somewhere a quick note what you can do with qualcomm hardware while full control is assumed
<ssvb>
sigh, which part about *usb* did you not understand?
xes has joined #linux-sunxi
<swiftgeek>
i understand consequences
<swiftgeek>
starting from power consumption, lack of control and ending on MitM
<swiftgeek>
and total lack of security features
Ntemis has quit [Remote host closed the connection]
<ssvb>
you already have MitM with your ISP
<ssvb>
and yes, power consumption is an issue, but it's all about tradeoffs
<swiftgeek>
but at least it doesn't stick to the endpoint (mitm)
<swiftgeek>
in theory there is a way to connect qualcomm soc in way that will put Allwinner SoC in control
avph has quit [Ping timeout: 265 seconds]
<swiftgeek>
but then you need to write firmware for it -.-
<swiftgeek>
(samsung pulled out this few times )
<ssvb>
if we are really paranoid, then we can't fully trust Allwinner either
<ssvb>
they can easily integrate an extra CPU core without telling anything to anyone :)
<ssvb>
admittedly, the SoCs which are booting in non-secure mode are a lot worse in this respect
avph has joined #linux-sunxi
domidumont has quit [Read error: Connection reset by peer]
cosm has joined #linux-sunxi
lemonzest has quit [Ping timeout: 252 seconds]
f15h has quit [Remote host closed the connection]
lemonzest has joined #linux-sunxi
<speakman>
libv: ssvb: Do you know any #define in either egl.h or eglplatform.h which will not exist in other packages of Mali drivers (where the fbdev_window.h is contained)?
<speakman>
Maybe that's enough to figure out which fb header file to load?
<speakman>
Or do you have any idea where the fbdev_window.h originates from?
<libv>
speakman: if [ -e $includedir/EGL/fbdev_window.h ]; then
<libv>
that probably needs like {} quoting or something
<ssvb>
speakman: I think that this particular problem can't be resolved without a runtime check
<ssvb>
of course, if you want your application to be compatible with different GLES drivers without recompiling it
<speakman>
No not necessarily. It just have to pick the right header during build (and the right native window datatype)
<speakman>
And EGL.h is common for both, so I was hoping there was defines in the open source version which is not available in the commersial one.
<speakman>
I can't even find where the fbdev_window.h propritary file originates, all I can find is there it's manually added to different projects.
<ssvb>
and then you get a mali-specific build of your application, which is a great idea for packaging it in a device agnostic linux distribution ;)
<mibofra>
you're mali addicted developing and developing drivers for them.
<mibofra>
lol
<mibofra>
I've sent a mail to the cubietech guys
<ssvb>
wat?
<ssvb>
ok, thanks, please let us know if you get a reply from them
<speakman>
ssvb: Not sure we're talking about the same thing here.
<ssvb>
speakman: hmm, and then the binary only works on this particular platform?
<speakman>
ssvb: yes, that's sort of the whole point :)
<ssvb>
or do they build multiple backends and still select the right one at runtime?
<speakman>
ssvb: The main problem is Qt tries to be smart, which never works as expected.
<speakman>
ssvb: During the config part of Qt build, it tries to find out which EGL library is installed and available, hence those different tests.
<speakman>
ssvb: Problem is; it think "fbdev_window.h" and it's typedef "fbdev_window" is a requirement to build the Mali EGLFS platform support, which we in here all knows is NOT a requirement.
<libv>
speakman: then make that config more intelligent
<libv>
do not let it stupidly include a package without verifying that it is actually there
<libv>
err, s/package/header/
<speakman>
ssvb: I have no idea how they could end up in this conclusion, but they did. Now I'm trying to find a more suitible way to detect a Mali system which also works with any commercial Mali versions (if there is one, I still havn't found out where that fbdev_window.h originates)
<speakman>
libv: yes, that's one way to do it. I can even fork the eglfs-mali package into something like eglfs-mali-opensource, but those two packages would be almost identical which then makes it feel like a bad way to do it.
mibofra has quit [Ping timeout: 272 seconds]
<libv>
speakman: qmake should be able to handle both cases, and then provide a #define to have this file included directly
<libv>
it's really a trivial build system fix
<ssvb>
speakman: if you have several different GLES-capable devices, then maybe you can try to build and test https://github.com/ssvb/glmark2/commits/master (the fbdev variant of the program)?
<libv>
speakman: but it is not something that we at sunxi should or even can fix
<ssvb>
speakman: it worked with the sunxi mali drivers and also with libhybris for me, probably it should work fine with the other GLES/EGL drivers too
<libv>
speakman: this is a fix for the build at qt side
<ssvb>
and if not, then the runtime check can be probably extended to support them too
<speakman>
libv: Indeed that could be done. If the "commercial" Mali drivers, which includes the fbdev_window.h header file is called "eglfs-mali" what would be a descriptive name for this Mali version? eglfs-mali-opensource? Although it's not open source..?
<speakman>
libv: I'm trying to be that one patching Qt here :)
<libv>
speakman: we have the same struct defined in our fb headers
<ssvb>
speakman: everything that you want is a very simple struct with two fields (horizontal and vertical resolution)
<speakman>
libv: I just want to get your advice before doing anything stupid. I have no previous experiences with Mali drivers nor the Mali support on Qt.
<libv>
the qt code should just stop trying to include that header file if it is not present on the system
<ssvb>
speakman: you can probably contribute a patch to Qt and get rid of the fbdev_window.h header for good
<libv>
document why this is so in the .pro file, and you are done
<ssvb>
speakman: just declare the 'fbdev_window' struct locally without including the header
<speakman>
How about just malloc:ing a block of, let's say, 128 bytes and remove any use of fbdev_window? :D
ZbooNet has joined #linux-sunxi
avph has quit [Ping timeout: 268 seconds]
<ssvb>
speakman: and it is probably still a good idea to have a runtime check to ensure that the system has a (compatible) mali kernel driver
<speakman>
ssvb: I'll keep that in mind for further development (y)
avph has joined #linux-sunxi
<ssvb>
speakman: you don't need 128 bytes, you need a simple structure, providing the information about the size of the screen
<speakman>
2 x unsigned shorts? That would do?
<ssvb>
yes
<libv>
would this not risk further muddling up things?
<libv>
nobody would know why this would be necessary
<ssvb>
and again, having a runtime check here is a basic common sense (you don't want to pass a pointer to this structure to non-mali GLES/EGL implementations)
<speakman>
Well, that does makes sense... But then it will fail "probing" the right platform during config. :/
premoboss has joined #linux-sunxi
<ssvb>
does Qt have some sort of a generic GLES/EGL backend?
<speakman>
ssvb: Yep, that's step 2. Now it won't compile the eglfs-mali platform support at all unless it can't include "fbdev_window.h". It seems like that header file is the main deal determining if it's Mali or not.
<speakman>
ssvb: Yes it does
<speakman>
ssvb: First it got general EGLFS support. Then it adds platform-specific init procedures.
<speakman>
Seems like different platforms have different ways to set up the "native window" (which I think is some sort of "root" window?)
<ssvb>
support for mali could be integrated into the generic backend, and enabled based on a runtime check
<ssvb>
if Qt has a concept of probing different backend to find a compatible one, then this can work too
<speakman>
That would indeed be a better way, is my opinion as well. Just compile and include every available platform support, and call the right one during runtime.
<speakman>
I *think* it also does this determination during runtime. So having them all built-in would probably help a lot. That reminds me I need to dig into how this is determined runtime!
<libv>
ssvb: that would mean that either qt comes with the egl platform header files for all supported platforms
<libv>
or that it wildly defines structs itself everywhere
<libv>
yes, egl for fb is broken, but there must be some limits to the madness
avph has quit [Ping timeout: 260 seconds]
avph has joined #linux-sunxi
<speakman>
:D
<speakman>
ssvb: libv: Regarding "egl for fb is broken"; what is the current best way to utilize the GPU on A20? I though EGLFS was The Way, but maybe it's more convenient running everything through X11?
<speakman>
My main goal is to have a Qt 5.5 based web browser running full screen on an A20 board (Olimex).
<ssvb>
speakman: the framebuffer mali driver will have less overhead
<speakman>
Qt does support many different approches, I found EGLFS the most plain and simple way - maybe that's not true? Or maybe there is even more convenient ways? How is Wayland going these days?
<speakman>
ssvb: ok, I guess that's eglfs?
<speakman>
wait - is "eglfs" a pure Qt term?
<ssvb>
yeah, that's what I was about to ask you :)
<speakman>
LOL!
FDCX_ has quit [Read error: Connection reset by peer]
<speakman>
I've been think it was a (E)GL term in general! :D :D
<speakman>
Sorry for all the confusion that created. :D
<ssvb>
regarding Wayland, supporting it is up to the driver developer (which means ARM)