Turl changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi
MackBoy has joined #linux-sunxi
petr has joined #linux-sunxi
leviathancn has quit [Ping timeout: 265 seconds]
uniqdom has quit [Ping timeout: 245 seconds]
bonbons has quit [Quit: Leaving]
FDCX_ has quit [Ping timeout: 245 seconds]
iamfrankenstein has quit [Quit: iamfrankenstein]
zombu2 has quit [Ping timeout: 255 seconds]
Andy-D has quit [Ping timeout: 265 seconds]
Andy-D has joined #linux-sunxi
orly_owl has quit [Ping timeout: 264 seconds]
naobsd has quit [Quit: naobsd]
naobsd has joined #linux-sunxi
allen has quit [Ping timeout: 250 seconds]
popolon has quit [Quit: WeeChat 1.1.1]
egbert has quit [Disconnected by services]
egbert has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
Black_Horseman has joined #linux-sunxi
orly_owl has joined #linux-sunxi
khuey is now known as khuey|away
allen has joined #linux-sunxi
orly_owl has quit [Quit: leaving]
orly_owl has joined #linux-sunxi
akaizen has joined #linux-sunxi
p1u3sch1_ has joined #linux-sunxi
sehraf has quit [Quit: www.miranda-fusion.de ... be part of it...]
p1u3sch1 has quit [Ping timeout: 240 seconds]
<Turl> atsampson: afaik the dt overlays is some proprietary stuff the bbb people came up with, there's no equivalent for sunxi
gjm has quit [Ping timeout: 256 seconds]
gjm has joined #linux-sunxi
gjm has quit [Changing host]
gjm has joined #linux-sunxi
leviathancn has joined #linux-sunxi
leviathancn has quit [Ping timeout: 265 seconds]
deffrag has joined #linux-sunxi
Netlynx has joined #linux-sunxi
Netlynx has joined #linux-sunxi
gaara has joined #linux-sunxi
FreezingCold has joined #linux-sunxi
FreezingCold has quit [Remote host closed the connection]
FreezingCold has joined #linux-sunxi
leviathancn has joined #linux-sunxi
cubear has joined #linux-sunxi
allen has quit [Ping timeout: 256 seconds]
reinforce has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
jinzo has joined #linux-sunxi
pmattern has joined #linux-sunxi
<mripard_> Turl: not really
<mripard_> DT overlays are generic
<mripard_> the driver to load them automatically (capemgr) is not
Andy-D has quit [Ping timeout: 265 seconds]
Seppoz has quit [Remote host closed the connection]
Seppoz has joined #linux-sunxi
Andy-D has joined #linux-sunxi
hipboi has joined #linux-sunxi
bonbons has joined #linux-sunxi
hipboi_ has quit [Ping timeout: 265 seconds]
Black_Horseman has quit [Ping timeout: 264 seconds]
Black_Horseman has joined #linux-sunxi
allen has joined #linux-sunxi
Andy-D has quit [Ping timeout: 264 seconds]
Andy-D has joined #linux-sunxi
sehraf has joined #linux-sunxi
sehraf has quit [Client Quit]
sehraf has joined #linux-sunxi
paulk-aldrin has joined #linux-sunxi
kevinsan has quit [Ping timeout: 252 seconds]
kevinsan has joined #linux-sunxi
f15h has joined #linux-sunxi
Netlynx has quit [Quit: Leaving]
allen has quit [Remote host closed the connection]
uniqdom has joined #linux-sunxi
leviathancn has quit [Ping timeout: 265 seconds]
FR^2 has joined #linux-sunxi
diego71 has quit [Ping timeout: 265 seconds]
diego71 has joined #linux-sunxi
f15h has quit [Remote host closed the connection]
ssvb has quit [Ping timeout: 240 seconds]
MY123 has joined #linux-sunxi
ssvb has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
Black_Horseman has quit [Remote host closed the connection]
ricardocrudo has quit [Ping timeout: 245 seconds]
ssvb has quit [Ping timeout: 245 seconds]
paulk-aldrin has quit [Quit: Quitte]
iamfrankenstein has quit [Quit: iamfrankenstein]
ssvb has joined #linux-sunxi
MY123 has quit [Quit: Leaving]
tomboy64 has quit [Ping timeout: 272 seconds]
cnxsoft has quit [Ping timeout: 265 seconds]
tomboy64 has joined #linux-sunxi
leviathancn has joined #linux-sunxi
ssvb has quit [Ping timeout: 246 seconds]
interrobangd has joined #linux-sunxi
<uniqdom> thanks libv
<uniqdom> I have an Olimex A20-OLinuXino-Micro, but it still have the A20
<Turl> mripard_: hmm, you learn something everyday :)
leviathancn has quit [Ping timeout: 256 seconds]
Froolap has joined #linux-sunxi
afaerber_ has joined #linux-sunxi
afaerber has quit [Ping timeout: 255 seconds]
afaerber_ is now known as afaerber
leviathancn has joined #linux-sunxi
ssvb has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
dev1990_ has joined #linux-sunxi
dev1990 has quit [Ping timeout: 240 seconds]
interrobangd has quit [Read error: Connection reset by peer]
lucaswang has joined #linux-sunxi
<rellla> jemk: ping
akaizen_ has joined #linux-sunxi
akaizen has quit [Ping timeout: 256 seconds]
gaara has quit [Remote host closed the connection]
gaara has joined #linux-sunxi
leviathancn has quit [Quit: No Ping reply in 180 seconds.]
f15h has joined #linux-sunxi
leviathancn has joined #linux-sunxi
iamfrankenstein has joined #linux-sunxi
<libv> uniqdom: that's still the most powerfull and most free hw out there
<uniqdom> :)
ricardocrudo has quit [Ping timeout: 256 seconds]
<jemk> rellla: pong
f15h has quit [Remote host closed the connection]
<rellla> jemk: you may have a look at https://github.com/rellla/libvdpau-sunxi/tree/dev
<rellla> deinterlacer support and own thread for displaying. works now very good with VDR
<jemk> rellla: i tried it 2h ago, there it crashed mpv, but looks like you changed something
<rellla> i missed some thing while rebasing. vdr is working now. you may test it with mpv/ mplayer. i have libav/ffmpeg issues here...
lucaswang has quit [Ping timeout: 245 seconds]
<rellla> vdr + ffmpeg(built myself) is ok.
<jemk> seems to work now, but 80% cpu for mpv where master had 10%
<rellla> but with libav it has high cpu load.
<jemk> and if i turn off OSD the window stays empty
<rellla> mpv (deb) needs libav :(
<rellla> which branch do you use?
<jemk> rellla/dev
<rellla> pulled recently?
<jemk> 3min ago
<jemk> the empty window without osd is because you removed xclearwindow
<rellla> yes, maybe. johns idea :p
<jemk> if i undo that it works but cpu usage gets even higher
<jemk> (which is obviuos)
<rellla> do you work with ffmpeg or libav?
<jemk> pacman -Qi mpv -> Hängt ab von : ffmpeg
<jemk> so i guess its ffmpeg
<rellla> i'll have to compile mpv with ffmpeg myself, so i can test that, too.
<jemk> same high cpu usage with vdr
MY123 has joined #linux-sunxi
<jemk> looks like you have a busy loop in the presentation thread wasting cpu time
<rellla> hm. i'll have a look later. maybe i messed sth during the 1000 rebases :(
<jemk> this loop is spinning while queue is empty, wasting all cpu time
<rellla> jemk: maybe we can do some usleep + continue, when queue is empty?
<rellla> 20ms for example
<rellla> or just do the vsync outside the if
<jemk> clean solution would be to block while queue is empty, vsync outside could help too
<ssvb> the FBIO_WAITFORVSYNC ioctl is probably even not needed at all
<ssvb> the disp layer updates are in fact taking effect on vsync
<jemk> it is only "needed" to get the vsync timestamp, but that should better be solved correctly
xeros has joined #linux-sunxi
<ssvb> ok, then just moving vsync outside the 'if' construct should indeed solve the problem and work as a kind of ~17ms sleep
<ssvb> but if the video is paused and the queue is empty, then such wakeups will only drain the battery
<jemk> i would like a select() with queue_empty, xevents and vsyncs
<jemk> but it think FBIO_WAITFORVSYNC can't be used in select()
leviathancn has quit [Ping timeout: 265 seconds]
<ssvb> jemk: btw, the order of actions seems to be backwards
<ssvb> the FBIO_WAITFORVSYNC ioctl and saving 'frame_time' probably needs to be done after do_presentation_queue_display(task)
<ssvb> because that would be the time when the user sees the frame update on screen
<ssvb> or more like the timestamp should be saved to 'os->first_presentation_time' after FBIO_WAITFORVSYNC
<jemk> well, yes, after thinking about it
<jemk> but to be correct, a vsync could happen between setting up disp and calling FBIO_WAITFORVSYNC
<ssvb> yes, but the window of possible error is much smaller this way
<jemk> sure, only wanted to notice that
<jemk> every time i think about all this output stuff, i notice how many problems disp has and decide to wait for a kms driver...
<ssvb> :)
<jemk> now rellla tried to improve it, and i again think about how much easier it should be
<jemk> s/easier/cleaner/better/whatever/
<ssvb> kms is not a silver bullet either
<ssvb> check a recent blog post: http://keithp.com/blogs/MST-monitors/
<jemk> yes, but i would prefer helping to fix kms than to fix disp
<ssvb> this blog post explains that "All Our APIs Suck" :)
<libv> if keithp hadn't shot me down, his apis wouldn't suck as much.
ssvb has quit [Ping timeout: 246 seconds]
<jemk> but at least the MST problem was never meant to work that way, some clever engineers abuse it that way
kenny has quit [Remote host closed the connection]
ricardocrudo has joined #linux-sunxi
ssvb has joined #linux-sunxi
<ssvb> jemk: basically, it's up to us to contribute a basic kms driver to the mainline kernel (with the features, sufficient for video playback)
ricardocrudo_ has joined #linux-sunxi
<ssvb> all the other nice features, such as hotplug and multi-monitor support can be implemented later
ricardocrudo has quit [Ping timeout: 250 seconds]
<plaes> ssvb: IIRC, libv already has something, but well...
<ssvb> plaes: but what?
<plaes> no sign of that :(
<ssvb> plaes: frankly speaking, libv has more interesting and challenging reverse engineering tasks than just spending time on a simple kms driver
<ssvb> this whole kms thing is just converting the existing code from one api to another, and fixing bugs in the process
<plaes> mhm
<libv> heh.
<plaes> o/
<libv> ssvb: remember what i said in august, when i threw out the uboot code.
<plaes> libv: what's the relation between g2d and kms?
<ssvb> plaes: there is no direct relation, and g2d is even not supported in some soc variants
<jemk> I don't expect a fully functional kms driver to magically appear, I'm ready to help coding whereever i can, but I don't want to start from scratch
<plaes> hmm.. http://linux-sunxi.org/Used_IP_cores doesn't mention where g2d is available
<MY123> plaes, it is not available in A23
uniqdom has quit [Quit: Ex-Chat]
<ssvb> jemk: the display controller support code has been already distilled in u-boot
<ssvb> jemk: we can take it, move into the kernel and add planes (layers) support
<libv> hrm.
<jemk> I think that's what libv meant should not happen
<libv> jemk: i cannot stop him.
<ssvb> why not?
<ssvb> the development needs to be driven by practical needs, simplefb solves the problem of having some sort of graphics support and provides basic desktop
<ssvb> now the next step is either a nice multi-monitor support, or the video playback acceleration
<plaes> I would go with video
<MY123> libv: Does CedarX have a blob in the ROM?
<jemk> libv: what is missing in your kms why you don't want to release it?
<ssvb> libv: we can skip the "followed by calling me a poopoo" part :)
<MY123> (I strongly expect it)
<jemk> MY123: no, not as far as i knwo
<plaes> :D
sehraf has quit [Read error: Connection reset by peer]
<MY123> jemk: I once saw a system where there was a full ThreadX and a custom JVM in microcode
<ssvb> libv: in fact, I think that you make a great contribution to the u-boot video support and deserve a proper credit for that
sehraf has joined #linux-sunxi
<MY123> * ROM code
<ssvb> s/make/made
gaara has quit [Ping timeout: 250 seconds]
ricardocrudo__ has joined #linux-sunxi
ricardocrudo_ has quit [Ping timeout: 250 seconds]
<jemk> MY123: well, there likely is some sort of microcode/rom, but at least there is no firmware doing all the work like in many other vpus
ricardocrudo__ has quit [Ping timeout: 252 seconds]
ricardocrudo__ has joined #linux-sunxi
ricardocrudo_ has joined #linux-sunxi
Vespine has joined #linux-sunxi
ricardocrudo__ has quit [Ping timeout: 256 seconds]
<jemk> libv: I somehow understand why you don't want to release it unfinished, seen that with cedrus/libvdpau. But I'm close to supporting ssvbs way now, as it looks like we would wait forever otherwise
cubear has quit [Ping timeout: 272 seconds]
<Turl> libv: there's competent, reasonable people willing to help get it finished, if I were you I'd take them on their offer :)
* plaes goes back to work on BDOC
<Turl> plaes: what's that?
<plaes> Digital Signatures
<jemk> bbl
<plaes> not related to sunxi :P
deffrag has quit [Remote host closed the connection]
deffrag has joined #linux-sunxi
<MY123> plaes, Please not
<MY123> that can be used for evil purposes
<plaes> I know
<MY123> plaes, I'm scared enough of Windows RT
<plaes> um.. how is that related? :)
<Turl> MY123: looks like digital signatures for invoices, tax returns and the like
<plaes> also online banking
<MY123> Turl, someone can use his work to sign exes
<MY123> (and block any non-signed program)
<plaes> MY123: not related
<MY123> plaes, a certificate system would be needed
<MY123> Web-Of-Trust is not sufficient for invoices
<plaes> MY123: read here: http://www.id.ee/index.php?id=30470
ricardocrudo_ has quit [Ping timeout: 256 seconds]
<MY123> Writing it in Malbodge would be fun
<MY123> (especially the kernel-mode driver)
pmattern has quit [Quit: Genug für heute.]
ricardocrudo_ has joined #linux-sunxi
premoboss has quit [Remote host closed the connection]
indy_ is now known as indy
ricardocrudo_ has quit [Ping timeout: 240 seconds]
ricardocrudo_ has joined #linux-sunxi
<MY123> jemk, :-)
ricardocrudo_ has quit [Ping timeout: 246 seconds]
<ssvb> jemk: the LGPL license in action :) They could have kept your copyright though
ricardocrudo_ has joined #linux-sunxi
<oliv3r> jemk: very interesting
<oliv3r> did you lgpl it or agplv3 it? :)
<oliv3r> if lgpl, you can't even use it to get the cedar code
<ssvb> oliv3r: better forget about harassing allwinner to get the cedar code
<ssvb> IMHO trying to do this by "force" is not going to end up well
<ssvb> libv: sorry, I had to go afk right when the kms things got interesting (had to do laundry)
<jemk> Its lgpl, so it's ok, but it's funny
cooper__ has joined #linux-sunxi
interrobangd has joined #linux-sunxi
<cooper__> Thought I'd hop by for a quick update. Been compiling all day and everything's rock-solid. One job error'd out but that was due to an OOM (forgot to enable my swapfile). Only 28 packages remain at which point I'll try my previous kernel again.
xeros has quit [Ping timeout: 272 seconds]
MY123 has quit [Quit: Leaving]
interrobangd has quit [Read error: Connection reset by peer]
tomcheng76 has quit [Read error: Connection reset by peer]
tomcheng76 has joined #linux-sunxi
iamfrankenstein has quit [Quit: iamfrankenstein]
<rellla> seems much better now.
<rellla> 10% cpu at 576i, 18% at 720p in vdr
premoboss has joined #linux-sunxi
<rellla> but what i get from time to time is this nagging message:
<rellla> [DISP] not supported image0 pixel sequence:11 in img_sw_para_to_reg
<rellla> repeating ....
<rellla> i know, disp driver is a mess, but any hints, where this may come from? ssvb ^^ :p
<rellla> display is ending up with artifacts, wrong colors etc.
<ssvb> rellla: can't say anything offhand, this needs to be debugged
<jemk> rellla: cpu usage looks good now
ricardocrudo_ has quit [Ping timeout: 250 seconds]
<rellla> ssvb: i had this errors time ago with xbmc. must read the code, what register values/ ioctls can lead to this message... it's bad, but not the main problem atm :)
<rellla> jemk: sounds good. any chance to get that upstream? i suggest to do a dev branch.
<jemk> rellla: These disp messages seem to happen randomly, i have them sometimes too
<rellla> even if you guys wanted to stop improving that, it's working and raised the amount of people that are interested in. we have the vdr community now.
<ssvb> maybe some uninitialized variables in some structs...
<rellla> i think it runs better on a10/a20 than on rpi/rpi2. and thats good :p
<jemk> what's the benefit of the presentation_thread at present? I can't see any difference in video playback
<rellla> ssvb: yes, i found the responsible function a time ago. there were missing some parameter in a DISP_..._SET_... anything iirc
<jemk> but with some cleanup and the XClearWindow readded i think it would be ok
<jemk> or better with some X event loop ;)
<rellla> jemk: it's the api of vdpau iirc. it's buffering the tasks and doing the displaying in a separate task.
ricardocrudo_ has joined #linux-sunxi
<rellla> jemk: is the Xevent loop only a if (expose) {XClearWindow} ... is it that easy?
<rellla> jemk: should i do a pull request?
<rellla> or push it myself?
ricardocrudo__ has joined #linux-sunxi
nove has joined #linux-sunxi
ricardocrudo_ has quit [Ping timeout: 250 seconds]
<jemk> If you clean it up before i think you can push it to a dev branch yourself
ricardocrudo has joined #linux-sunxi
<rellla> comments etc. ?
<rellla> debug..
<jemk> and the event loop, it should be used to get recent window position and move the layers too, then it gets more complicated
ricardocrudo__ has quit [Ping timeout: 250 seconds]
<rellla> i think, i can't do that. at least not quickly. not clue what to do atm *rolleyes*
<rellla> ssvb: saw my v3 patch of disp csc fix?
<jemk> rebase to masterand squash the fixes to have clean commits to see what changed would be good
<nove> jemk: just to say that, i will not pass the new blobs by the laundry until if even i get h265 capable hardware, or you ask me
<jemk> nove: i don't have h265 hardware too, so no hurry
<rellla> jemk: can you please ask nove to pass them to valgrind ammt to find out how to use the maf registers ? :p
<rellla> jemk: i will rebase them, clean it up and push it to a new dev branch. the next days.
<ssvb> rellla: yes, just get somebody's ack (jemk's?) and we should push it in
<rellla> ssvb: maybe we should first test them. /me didn't ;) but theoretically it seems ok.
<ssvb> rellla: I was supposed to look at what's up with the sunxi-3.4 kernel, but was distracted by unrelated things again
<rellla> i don't know how to use csc in practice. libvdpau-sunxi should be capable of doing sth with it.
<ssvb> rellla: testing patches before pushing is a very good idea, that's the whole point of the code review, etc. :)
<rellla> ssvb: as i said. i don't know how ;)
<ssvb> rellla: if you can't reproduce the problem, then why bother "fixing" this then?
<jemk> rellla: I actually don't know how to use the csc myself, someone else added that, and it didn't break anything, so i merged it ;)
<rellla> jemk: i did some theoretical redo of the csc thing in libvdpau-sunxi based on vl_csc code.
<rellla> ssvb: because it's obviously bogus code
<rellla> *surely
<ssvb> rellla: just find a way to test it :)
<rellla> ssvb: no time. i have to rebase vdpau code :)
<ssvb> nobody has time
<jemk> and here again, the correct fix would be to pass the real csc matrix to disp instead of converting the bright/sat/cont/hue from player to csc for vdpau to bright/sat/cont/hue for kernel to csc for hardware
<rellla> ok. ok. i will find out how to ue it.
<jemk> only mentioning, you don't have to do that
<rellla> jemk: player bright/sat/cont/hue -> vdpau csc -> disp csc
<rellla> ?
<jemk> yep
<jemk> some DISP_CMD_LAYER_SET_CSC like ioctl
<rellla> jemk: not with the sunxi-3.4 display driver.
<rellla> not without writing a new ioctl.
iamfrankenstein has joined #linux-sunxi
<rellla> jemk: we can pass the single values directly to disp via ioctl. no need to create the csc matrix in in vdpau (for sunxi). only for completition.
<rellla> *the single procamp values
<jemk> rellla: that's how we do it currently i think
xenoxaos has quit [Remote host closed the connection]
<jemk> in set_csc_matrix the matrix gets converted to b/s/c/h to pass it to the kernel, and the kernel converts it back to the matrix
<jemk> passing the matrix directly would solve all these problems
<rellla> yes, but then we have to patch the (deprecated) kernel
<jemk> exactly, that's why i don't touch this ;)
<rellla> jemk: there is no way to get b/s/c/h directly from vdpau other than from the csc matrix?
mmarker1 has joined #linux-sunxi
<rellla> vdpau creates a csc matrix with the given procamp values, and the only way to get these values is redoing the csc matrix? that sounds very bogus ...
<jemk> the vdpau videomixer api only has a VDP_VIDEO_MIXER_ATTRIBUTE_CSC_MATRIX
<jemk> no attribute_bright/sat/...
<jemk> thats not bad, gives the player much more control
mmarker has quit [Ping timeout: 252 seconds]
deffrag_ has joined #linux-sunxi
deffrag has quit [Ping timeout: 246 seconds]
ricardocrudo_ has joined #linux-sunxi
ricardocrudo has quit [Ping timeout: 245 seconds]
Andy-D has quit [Ping timeout: 245 seconds]
xenoxaos has joined #linux-sunxi
koza has joined #linux-sunxi
koza is now known as mzki
FreezingCold has quit [Remote host closed the connection]
ricardocrudo__ has joined #linux-sunxi
ricardocrudo_ has quit [Ping timeout: 244 seconds]
Froolab has joined #linux-sunxi
ricardocrudo__ has quit [Ping timeout: 245 seconds]
Froolap has quit [Ping timeout: 240 seconds]
<ssvb> libv: regarding the kms driver, it just needs to be implemented at some point
<ssvb> jemk and rellla obviously want it sooner than later
<ssvb> and it does not mean that we need to listen to some loud pricks in the mailing list
ricardocrudo__ has joined #linux-sunxi
<ssvb> yes, mainlining the kms driver is somewhat tricky because it does not require any exceptional skills, but is a rather sizable piece of work that just needs to be done
f15h has joined #linux-sunxi
<ssvb> too many people are familiar with this stuff and will feel an urge to express their opinion, similar to what has happened with simplefb :)
xeros has joined #linux-sunxi
FR^2 has quit [Quit: Leaving]
Esmil has quit [Remote host closed the connection]
<hno> Happy happy days. bootloader & NAND code GPL again.
f15h has quit [Remote host closed the connection]
Vespine has quit [Quit: Leaving]
deffrag_ has quit [Ping timeout: 245 seconds]
popolon has joined #linux-sunxi
Froolab has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/]
Froolap has joined #linux-sunxi
nove has quit [Quit: nove]
iamfrankenstein has quit [Quit: iamfrankenstein]
reinforce has quit [Quit: Leaving.]