<ssvb>
techn_: maybe was a bit too slow to notice, but A13 User Manual has documentation for "Display Engine Front End (DEFE)" and " Display Engine Back End (DEBE)"
<ssvb>
techn_: did you have a look at it? that's basically what we need to know for implementing a decent disp driver
<mripard>
Turl: :)
<ssvb>
techn_: I mean I was too slow to notice, just spotted it yesterday and had a good read, many things seem to be much more clear
<techn_>
ssvb: yeah.. I noticed it.. but havent yet looked it close
<techn_>
ssvb: After I finish that usb stuff I'll move back to disp
<ssvb>
now developing a new disp driver from scratch for the mainline kernel does not look like a bad idea to me
<techn_>
Next for disp is to use that pwm driver :/
hglm has quit [Quit: Lost terminal]
<techn_>
maybe make proper lcd module, which uses lcd framework and pwm driver :/
<techn_>
I leaked drm driver skeleton accedently ;)
<techn_>
it is just skeleton, which has hdmi edid stuff partially implemented
<techn_>
clock init etc missing
<techn_>
but co-works with current fbdev driver
<n01_>
oliv3r: ping
_BJfreeman has joined #linux-sunxi
_BJfreeman is now known as BJfreeman
<Turl>
mripard: btw, mmc clocks should be working except for pll6, let me know if/when you want to start with that and I'll push a cleaned branch for you
<Turl>
I need to clean and document it a bit but it should be usable
<mripard>
Turl: great, thanks :)
<Turl>
mripard: once we have mmc and usb, (that I heard is pretty much supported already? :) ) I can move my home server to mainline
<mripard>
Turl: for the musb stuff, Arnd was saying it would probably not be just as trivial as adding the driver in the dt, because the vendors tend to adapt it somehow
<mripard>
but yeah, it should way easier than expected
<Turl>
mripard: for a start I need to implement some other clocks :P
wingrime has joined #linux-sunxi
<lkcl>
aseigo: ping. i just compiled sunxi_fb and sunxi lcd as optional
<lkcl>
then modprobe'd them - got a segfault because, i think, i had set lcd to *off* in the script.fex file
<hramrach_>
.
<notmart>
hmm, lcd seemed enabled in the fex
<lkcl>
notmart: ok.
<aseigo>
lkcl: we have xorg up on the device btw :)
<lkcl>
woo!
<lkcl>
well that was quick
<aseigo>
yeah. running applications linking to libplasma and everything
<lkcl>
yaaaaaaah
<lkcl>
waa not fair - i want some!
<aseigo>
still work to be done, but this is one of the big humps
<lkcl>
ack
<notmart>
yeah, i got xorg showing once
<lkcl>
if you use usb networking you can at least get access to the internet
<aseigo>
accel X + stm32f2 driver is the next
<notmart>
doesn't *always* bring up graphics output tough
<aseigo>
yeah, i want to experiment with that next
<aseigo>
yes, we're not sure why it doesn't always output to the screen yet (it gets signal on hdmi, fb0 is there, etc.)
<lkcl>
yehh i've found that if i start up with the RS232 plugged in _and_ HDMI i think there's some interference
<aseigo>
i suspect it might be because i'm doing hdmi->dvi .. which has given me problems with other arm boards. we're about to try it pure-hdmi on the t.v.
<lkcl>
ahh ok.
<aseigo>
if it comes up reliably on the television, then that's what it is
<aseigo>
if it isn't .. then we need to dig more
<aseigo>
but yeah .. hooray for progress
<lkcl>
it's most likely a power issue
<aseigo>
and this is with a full systemd driven user space and everything
<lkcl>
i.e. not all the equipment is properly earthed
<aseigo>
like, a real, modern linux ;)
<lkcl>
yaaay
<lkcl>
wow
<aseigo>
images are building on the build servers too so we'll be able to offer those for downloads as nightlies (and provide for online pakcage updates from the command line, of course)
<lkcl>
oh ... there was a tool you should add.... what was it...
<notmart>
in theory should change something if the hdmi is attached befre or after powering on?
<lkcl>
git://github.com/hglm/a10disp.git
<lkcl>
aseigo, notmart: ^
<lkcl>
that's a tool for modifying script.bin stuff *dynamically* but specifically the display info
<lkcl>
so you can change resolution, change type, fps etc. to the [very specific!] supported resolutions on hdmi
<lkcl>
it then calls out to fbset afterwards.
<notmart>
this is something that should run on the device?
* aseigo
is also making up some spinach, ricotta and pine-nut filling for ravioli ... multitasking .. :)
<lkcl>
:)
<lkcl>
niiice
<notmart>
btw attaching ti to the tv doesn't seem to matter
<lkcl>
notmart: yes.
<notmart>
ok, will try to package it
<techn_>
ssvb: anyway.. I had idea to implement components which would be easy to move new architecture
<lkcl>
notmart: i think you might have to get proper earth grounding. try starting up *without* the HDMI lead plugged in
<lkcl>
then plug it in afterwards
<lkcl>
woo, usbnet is back!
<techn_>
ssvb: verify that components work with fbdev.. then integrate them to new clock system in sunxi-next
<hramrach_>
how do you use a webcam?
<notmart>
thing is that when is booting android video always seems to come up
<notmart>
even tough with colors altered in that neat pink
<hramrach_>
can like vlc show the picture off it? or something?
<lkcl>
notmart: hmmmm....
<lkcl>
notmart: they use that tool (or equivalent) - try grabbing it, setting up a compiler (under that debian root fs) and playing with it
<notmart>
yep, i will :)
<lkcl>
we get you networking up-and-running ok?
<lkcl>
Fetched 34.2 MB in 21s (1,613 kB/s)
<lkcl>
gotta love FTTC...
<lkcl>
euurgh, this £4 sdcard is truly dreadfully slow
<hramrach_>
or the mmc interface
<lkcl>
hramrach_: i have another sd/mmc card, it was actually quite reasonable
<hramrach_>
could not get any faster than 10 MB/s with a SD card on a10
<lkcl>
hramrach_: yuk.
<hramrach_>
then tried timing the USB readers and found they are abysmally slow
<lkcl>
hang on... 10mbytes/sec? that's like super-fast!
<lkcl>
or maybe i am used to computers from 5 years ago :)
<PiyushVerma>
Turl: now my desktop same but batter perofrmance I think
<hramrach_>
it still does not play anything, though
<rm>
does anyone have a Mele A2000G?
<ssvb>
PiyushVerma: unfortunately it's a bit of a fake (there is a comment about an annoying bug on resizing)
<Turl>
rm: the one with 1G ram?
<rm>
yes
<Turl>
rm: not me then
<rm>
I can't get it to boot, tried a10_mid_1g and mk802ii
<rm>
did not connect serial console yet
<ssvb>
PiyushVerma: thanks to certain quirks of the mali x11 egl blob, I don't know how to implement reliable zero copy DRI2 buffers swapping :(
<Turl>
rm: boot android, copy the a10 mem info static tool and dump the timings
<PiyushVerma>
ssvb: May be G2D can help
<PiyushVerma>
which transfer from memory to fb ?
<PiyushVerma>
Turl: Wow wayland is awsame
<PiyushVerma>
How to get it on A10
<hramrach_>
apt-get install wayland ;-)
<Turl>
ssvb: did you watch the wayland/weston video? :p
<ssvb>
PiyushVerma: yes, G2D can be used to fake buffers swapping with accelerated copy, but this is also not easy when talking to a binary blob on the other side
<Turl>
PiyushVerma: keep in mind it has no specific a10 support
<ssvb>
Turl: which is a bit unfair, but who cares :)
<PiyushVerma>
Turl: humm qt5 also use wayland
<wingrime>
mnemoc: can you give me place in dl folder
<wingrime>
for traces
<Turl>
ssvb: they make it sound like it'd be easier to implement though
<aseigo>
PiyushVerma: or x, or fb.. it's pretty flexible.
<hramrach_>
wayland kind of sucks. They aim to replace X with something more up to date with less cruft but it's falling apart before it's even finished. When it is it will have almost as much cruft as X has I suspect. monolithic design ..
<Turl>
ssvb: (G2D renderer)
<hramrach_>
well, maybe wayland+1 is going to make it
<wingrime>
svb: it difficlt to make xv for sunxi?
<Turl>
hramrach_: mer? :P
<hramrach_>
what is mer?
<Turl>
mir, sorry
<Turl>
ubuntu's take at X/wayland
<ssvb>
Turl: about "it'd be easier to implement" - this is not totally true, it's also easy to accelerate scrolling and moving windows in xorg (but not transparency or smooth transitions)
<hramrach_>
Ubuntu projects tend to suck but we well see what comes out of this one
<ssvb>
Turl: and they mentioned that they dropped rotation support in their wayland compositor because it did not map well to DispManX
<aseigo>
hramrach_: er.. falling apart before it's even finished? what do you mean?
<ssvb>
Turl: wayland/weston has more features, which can be accelerated, that's true
<ssvb>
wingrime: XV is easy, I'm just being lazy
<hramrach_>
I got interested in wayland
<hramrach_>
so was on the dev list for a while
<hramrach_>
they want everything integrated in a single wayland server process /o\
<ssvb>
wingrime: and I'm also anticipating people getting high hopes, trying to playback 1080p videos and complain :)
<ssvb>
wingrime: btw, it's one of the reasons why I looked at cedarx, libhybris, etc.
<PiyushVerma>
ssvb: Recently I did some testing
<PiyushVerma>
on cedar
<notmart>
hm, if i set pal display seems to enable
<PiyushVerma>
I think only treading between decode and display thread can make big difference
<PiyushVerma>
I want to do that but I need support on that
<PiyushVerma>
Some strange thing happen inside when apply thread and get segfault
<aseigo>
hramrach_: you mean the implementation of weston?
<wingrime>
ssvb: you can look at my results
<wingrime>
not much
<hramrach_>
aseigo: wayland. what is weston? some new wayland fork?
<Turl>
hramrach_: weston is the ref implementation of the wayland protocol
<ssvb>
hramrach_: google tells us that "Weston is the reference implementation of a Wayland compositor", which is kinda shitty and unusable at the moment
steev has quit [Ping timeout: 246 seconds]
<aseigo>
hramrach_: weston is a wayland compositor, and as Turl notes, it's the refernece implementation of it
<aseigo>
hramrach_: it's a little non-sensiscle to say "wayland server process" .. that's really the compositor
<hramrach_>
and there is no plan for non-shitty implementation so far afaik
<aseigo>
hramrach_: weston is indeed doing everything in a single process
<aseigo>
hramrach_: see, that's why you should make fewer assumptions ;)
<aseigo>
the wayland peeps are working on weston, yes
<aseigo>
we (kde plasma) are likely going to use it stripped down for the system compositor (used to manage the transitions between e.g. a log in screen and the user sessions, or between sessions)
<aseigo>
we also have kwin which can run as a wayland compositor
<aseigo>
in that case, we have kwin doing JUST compositing (+ managing the events forwarding to windows so things like x wayland works as expected; that happens in its own thread though)
<hramrach_>
but is designed as X11 window manager .. does not sound that awesome
<aseigo>
the desktop shell is a pure qml app that runs in its own process, which is "blessed" by the session compositor (e.g. kwin) so it can do things other apps can't (for security reasons)
<aseigo>
hramrach_: wrong
<aseigo>
hramrach_: it is a window manager and a compositor (which are two different parts of the code base, cleanly separated)
<hramrach_>
separate shell sounds interesting, yes
<aseigo>
hramrach_: both of those parts have backends
<aseigo>
one backend (obviously the oldest and most used and well tested) is for x11
<aseigo>
one backend is for wayland
<aseigo>
managing windows is managing windows; compositing is compositing
<aseigo>
it's true that kwin started as an x11 window manager, but the kwin team has been working for probably the last 18 months to make that a completely historical detail
<aseigo>
(the code base is a *lot* cleaner and more performant in process, which is a nice win)
<n01_>
guys, anyone working on the RTC?
<hramrach_>
the wayland people can't seem to get that managign windows is managign windows and compositing is compositing
<aseigo>
hramrach_: yeah, well, they can do what they want with weston :) we've got kwin+plasma (and enlightenment has their thing, and hawaii desktop their's, and ...)
<Turl>
n01_: on mainline?
<aseigo>
hramrach_: that's a nice thing about the design of wayland .. such design decisions are not baked in for everyone and it still avoids the x11 approach of not defining any mechanism
<ssvb>
aseigo: the cleaner and more performance code sounds rather promising in theory, I'm just waiting for a decent implementation (for several years already)
<ssvb>
aseigo: what's going to happen to raspberry pi specific code in the case of kwin?
<n01_>
Turl: yep
<Turl>
n01_: not that I've heard of, I'd say go ahead :)
<n01_>
:D good
<Turl>
n01_: and add your name next to it on the mainlining effort page, so other people know you're doing it
<n01_>
ok
<Turl>
n01_: better yet, move it to the WIP section :P
<aseigo>
ssvb: that would, if necessary, end up in its own backend. hopefully though opengl es would be enough
<aseigo>
lkcl: btw, the mode setting app works like a charm
<lkcl>
ok that's better
<lkcl>
oh good!
<aseigo>
lkcl: we have it packaged on OBS already too
<lkcl>
yaaay
<notmart>
lkcl: apparently if i switch to 720p works greap
<lkcl>
that's very cool
* notmart
tries to modify the fex to make it boot at that res
<aseigo>
lkcl: we've switched to our usual workflow of "build it on OBS, put it on the device" so that packages can be fetched by whomever and updated whenever
<shineworld>
aseigo, what Axx platform are you using ?
<aseigo>
shineworld: that's an a10, we'll be shipping with a20s, though.. it's an eoma68 device
<shineworld>
can you give me a link ?
<aseigo>
shineworld: lkcl is one of the primary people involved with it as well
<aseigo>
shineworld: we're building the vivaldi tablet around this
<shineworld>
cool
<shineworld>
thanks for links I'm looking for
<aseigo>
so soonish we'll have full devices you can buy with everything nicely documented, sources available and binaries you can pull from build.merproject.org (as well as adding your own there)
<shineworld>
seem an european project ... or I mistake ?
<aseigo>
one of the *very* nice things about the build system is that you don't have to set up a cross-compile system yourself and others can grab your packages (either manually download or via the command line over the network)
<aseigo>
shineworld: we work with people in asia as well, but a large chunk of the engineering is done in europe, yes
<lkcl>
shineworld: it's world-wide.
<aseigo>
shineworld: the OS (user space and UX) and hardware design is done here .. kernel work and additional hardware design with partners in asia
<shineworld>
because purchase from eastern is always a problem for my country when pieces (value amount is bigger than 50E) are more than one
<aseigo>
shineworld: with time we'll expand that to include more people if we have anything to say about it .. we'd love to have more people engaging with this platform
<aseigo>
shineworld: where are you?
<shineworld>
Italy, north-east (close to venice)
<aseigo>
(if i may ask :)
<aseigo>
ah, cool..
<aseigo>
notmart lives in torino :)
<aseigo>
(he's visiting me here in zürich for a week or so of hacking on this stuff ... )
<shineworld>
In that months I've used cubieboard to prepare 4 prototypes (running with different LCD/LVDS screen sizes) to use them in industry how HMI panels
<aseigo>
(well, this is what we do, just not always in the same room ;)
<ssvb>
aseigo: do you already have working a20 prototypes?
<shineworld>
Actually A10 is just to fit for my feet or a little below so I'm waiting for A20 or more
<aseigo>
ssvb: yes .. i haven't personally done a bring-up on one yet (though that is going to change soonish)
<shineworld>
During waiting I'm also trying IMx6 from Freescale
<notmart>
weeird, regardless of what i put in script.fex it always starts as 1920x1080
<aseigo>
notmart: it's just whatit likes ;)
<shineworld>
but cubieboard not passed all internal test (without full it of filters)...
<lkcl>
notmart:
<shineworld>
I'm in the early stage
<lkcl>
screen0_output_type = 3
<lkcl>
screen0_output_mode = 5
<ssvb>
aseigo: cool, I just wonder about the mali drivers there, is allwinner providing the necessary blobs?
<lkcl>
?
<aseigo>
ssvb: yes
<notmart>
lkcl: yep, that's what i have right now
<aseigo>
we've already done libmali+libhybris on a10
<notmart>
ah, no
<notmart>
whops ;)
<aseigo>
(will be same danceon a20)
<ssvb>
aseigo: hmm, I specifically asked whether it is possible to avoid libhybris :)
<lkcl>
notmart: ack
<aseigo>
ssvb: that would require a mali driver that isn't made for android. such things tend not to exist for any of the non-useless GPUs
<aseigo>
ssvb: hopefully that will change when we can show more volume to the ARM world .. right now they focus on android because that's the market they see
<Turl>
aseigo: they exist for A10 :p
<ssvb>
aseigo: there are x11 mali blobs for a10 (r3p0, r3p1) and for samsung exynos (r3p2)
<notmart>
yay, works great :)
<aseigo>
Turl: that don't link to bionic?
<ssvb>
aseigo: but x11 blobs have a number of bugs :( it would be better to have some universal library which could be used as a backend for implementing any egl
<aseigo>
(the open source lima effort is what i'd really like to see polished off)
<aseigo>
ssvb: aaah, the x11 blobs
<aseigo>
yeah
<ssvb>
yes, we need to get lima drivers faster
<PiyushVerma>
What is perfornace of Lima is it getting similer to mali in non X-Windows env. ?
<ssvb>
before mali400 becomes outdated :)
<lkcl>
PiyushVerma: ask on #lima
<PiyushVerma>
lkcl: Aah nice I did not notice that
<ssvb>
aseigo: I don't trust libhybris :)
<hramrach_>
PiyushVerma: the lima perf was on par with the blob driver when runnig some demo
<hramrach_>
but that was not full driver
<PiyushVerma>
hramrach_: I test arround 5 months before. Lima was rendering directly on FB and Mali off screen render was same perofrmance
<PiyushVerma>
as Mali not provide Direct FB Render so can't test that
<PiyushVerma>
but don't know today situation
<hramrach_>
waiting for something usable to get written
<ssvb>
hramrach_: is the rotating cube demo not usable enough?
<hramrach_>
well, if you are a gpu driver developer or know one you can try to help
<hramrach_>
ssvb: I want Mesa replacement
<hramrach_>
how do you link to rotating cube demo? ;-)
<hramrach_>
anyway, I am not even sure the code is available somewhere
<PiyushVerma>
hramrach_: I just know a bit gles2 and GLSL
<ssvb>
that's what I got from the lima repository
<hramrach_>
yes, seems the published code lags way behind the actual development
<PiyushVerma>
there is already build script just a bit path tune
<ssvb>
hramrach_: should we try to check what is still missing there for getting a full mesa implementation?
<hramrach_>
maybe
<PiyushVerma>
ok friends going to sleep now.
<hramrach_>
or bug libv to push out the code so we can see what is there
<lkcl>
hooraaaay! console
<lkcl>
ok PiyushVerma
<lkcl>
debian login:
<lkcl>
yaay
<PiyushVerma>
lkcl: Congratulation :)
<mnemoc>
wingrime: please give me your ssh public key to create your account for dl.linux-sunxi.org
<ssvb>
hramrach_: lima can work simultaneously with the binary driver, which makes everything a lot easier
<hramrach_>
you can have both fb and x11 blob working at the same time, too
<mnemoc>
:o
<ssvb>
hramrach_: yes, it means that we can try to "productize" lima and attempt to make it do useful things without regressing anything in the system
<hramrach_>
well, if the lima kernel interface differs from mali it might get more challenging
<mnemoc>
afaik lima is userspace-only
<ssvb>
hramrach_: lima is using the unmodified arm kernel driver
<hramrach_>
or it needs r3p2 now but a10 has r3p0
<ssvb>
lima code from the repository works with r3p0 kernel
<hramrach_>
yeah but it's old
<ssvb>
still it works
<ssvb>
that's enough
<hramrach_>
what does it do, actually?
<ssvb>
but yes, the compatibility breaks in the mali kernel driver are really annoying
<mnemoc>
can we upgrade the kernel's mali? i.e. do we have newer blobs?
<ssvb>
mnemoc: we may try to steal the mali r3p2 blobs from exynos, but that's kinda violates EULA
<mnemoc>
or, can we have a backward compatible r3p2?
<mnemoc>
hipboi!
<ssvb>
mnemoc: we can add r3p2 kernel module alongside with r3p0 in the kernel (selectable at compile time)
<hramrach_>
somebody hinted you can get r3p2 blobs directly from arm and avoid that EULA issue
<ssvb>
hramrach_: how so?
<hramrach_>
don't know the details, really
<hramrach_>
nad blobs are no there yet so maybe they were just talking nonsense
<ssvb>
hramrach_: some time ago I tried to search some information and encountered this answer in the mali support forum - http://forums.arm.com/index.php?/topic/16259-how-can-i-upgrade-mali-device-driver/page__p__39744#entry39744
<hramrach_>
hmm, so seems ARM refuses to give out libraries
<Turl>
qcom hands out libs for adreno from what I know, but haven't seen anything similar from ARM
<ssvb>
hramrach_: he did not mention that it was a userland blob, I think what he downloaded from malideveloper.arm.com was the open source kernel driver
<hramrach_>
yes, maybe. that post is quite unclear
<Turl>
ssvb: yeah malideveloper has kernel modules
<Turl>
and gralloc source
<ssvb>
hramrach_: especially considering that he adds " i try to google binary lib file libUMP.so libMali.so for mali r3p2-01rel0, but can find nowhere" :)
<ssvb>
hramrach_: looks like he gets the userland blobs from google
<ssvb>
hramrach_: :)
<hramrach_>
yes, google has many
<ssvb>
Turl: yes, that's the exynos blob, we can't legally use it
<hramrach_>
seems the newest code in lima repo is the fosdem demo
<hramrach_>
which should run q3 with precompiled shaders
<hramrach_>
or whatever fps they used for te demo
<aseigo>
q3a, yes
<ssvb>
hramrach_: the shader compiler is developed in a separate repository
<hramrach_>
yes, and was not integrated with lima at the time of the demo
<oliv3r>
mripard: I still don't see, how 'offset / 4' is the right offset. We need to read 32bits each time, So when I read byte 14, (base + 0x0c) and I take 14 / 4, i get 3. base + 3 isn't the same address
<oliv3r>
techn_: i'm working on the PWM driver, using the PWM framework makes it _really_ easy; i don't even have to look at dwilkins his patch really (thank you for that though)
<oliv3r>
ssvb: i'm slightly shocked you hadn't seen the disp section in the a13 manual yet :p makes me more hopefull though :)
ganbold__ has quit [Ping timeout: 252 seconds]
<ssvb>
oliv3r: I primarily used just a10 manual
ganbold_ has joined #linux-sunxi
ganbold__ has joined #linux-sunxi
ganbold_ has quit [Ping timeout: 252 seconds]
<wingrime>
ssvb: can you help "expian some short names
<wingrime>
I don't understand some short names
<oliv3r>
ssvb: i looked at both to update wiki in places, since a13 has things a10 lacks
eebrah_ has joined #linux-sunxi
<oliv3r>
mripard: i suppose i need to also use devm_ioremap_resource instead of of_iomap?
<oliv3r>
n01_: in your v4; fix that 0x0F to 0x0f :p
LoCoZeNoz_ZUE has quit [Ping timeout: 252 seconds]
<hno>
wingrime, indeed it is. If you build without CONFIG_FB_SUNXI_RESERVED_MEM or boot with sunxi_fb_mem_reserve=0 then the framebuffer is dynamically allocated.
wingrime has quit [Ping timeout: 264 seconds]
ganbold has quit [Ping timeout: 252 seconds]
ganbold has joined #linux-sunxi
wm_ has joined #linux-sunxi
LoCoZeNoz_ZUE has joined #linux-sunxi
<ssvb>
hno: hardware accelerated video is neither decoded nor copied to the framebuffer
<ssvb>
hno: just the disp layers are configured so that the scanout is done from the needed buffer
<hno>
ssvb, makes sense.
notmart has quit [Quit: notmart terminated!]
wm_ has quit [Ping timeout: 248 seconds]
tinti has quit [Quit: Leaving]
<Turl>
mripard: are you still around?
LoCoZeNoz_ZUE has quit [Remote host closed the connection]