ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | Wiki at http://linux-rockchip.info | Logs at http://irclog.whitequark.org/linux-rockchip | ML at http://groups.google.com/group/linux-rockchip
nighty has quit [Remote host closed the connection]
stdint_ is now known as stdint
wzyy2 has joined #linux-rockchip
vagrantc has quit [Quit: leaving]
nighty has joined #linux-rockchip
cnxsoft has joined #linux-rockchip
swabbles has joined #linux-rockchip
<swabbles> Anybody got Linux to boot on the Chromebook Plus yet?
<swabbles> I've got mine recently, pulled the chromeos-4.4 branch from the kernel repository in chromium sources, enabled CONFIG_VT, CONFIG_VT_CONSOLE, CONFIG_FRAMEBUFFER_CONSOLE, but still a black display.
<amstan> swabbles: i'm doing that right now
<amstan> swabbles: also, you're in luck, this got comitted 14 min ago: https://github.com/archlinuxarm/PKGBUILDs/tree/master/core/linux-gru
<amstan> leming: meanwhile in here :)
<swabbles> Ah, yes, I was hoping to find that.
<swabbles> 0002-temporary-hack-to-fix-console-output.patch
<swabbles> This explains everything.
<amstan> swabbles: well, so as you have it now it should work too
<amstan> you just need to press a key
<amstan> the display only refreshes when it gets an input
<amstan> due to panel self refresh being a little broken for fbcon
<swabbles> Not getting anything when I press a key.
<leming> happy to blaze the trail :P
<amstan> swabbles: well, it could be a lot of other things tbh, like how do you know it even boots?
<swabbles> amstan: I don't, I just expect it to be somewhere in the Linux boot process because it didn't beep when pressing Ctrl + U.
<swabbles> Trying those patches now though.
<amstan> swabbles: for example, i think if the kernel doesn't find the rootfs(like you messed up the cmdline) it'll just hang without much rebooting
<swabbles> Sure, then it will panic, and normally you would have a vt before this.
<swabbles> Were it not that they normally disable the VT stuff nowadays.
<amstan> fair enough
<amstan> so maybe you have both problems :)
<amstan> and doing any input to refresh the display doesn't help since after it panic's it doesn't really check input anymore
<leming> the hack patch isn't going to solve it.. it's going to be a config issue
<swabbles> But normally it panics after setting up the VT (on every other device I have been using).
<swabbles> leming: I noticed, still doesn't work for whatever reason.
<leming> check if you have CONFIG_DRM_FBDEV_EMULATION=y
<amstan> what i'm saying is that the VT doesn't really update because of this psr bug, the only way to make it show up is to do an input event, if it crashes before that you can't send it input
<stdint> LongChair, one thing I forget to tell you
<stdint> I write a new gstreamer plugin using the mpp api which could be found at github
<swabbles> amstan: ah right.
<swabbles> leming: that would make sense, ty.
<swabbles> It works now! :)
<amstan> swabbles: woo!
<swabbles> It kept spamming my display for a while though.
<swabbles> No idea why.
<amstan> i might have messed up my patch, i lost the bpaste link for the one i actually tested, and i made up another diff 30 min ago(haven't tested it)
<leming> i don't get any spam
<swabbles> I might be missing the firmware atm.
<swabbles> Let me check.
lkcl has joined #linux-rockchip
lkcl has quit [Ping timeout: 240 seconds]
lkcl has joined #linux-rockchip
tlwoerner has joined #linux-rockchip
tlwoerner has quit [Changing host]
tlwoerner has joined #linux-rockchip
athidhep has joined #linux-rockchip
feoafka has joined #linux-rockchip
athidhep has quit [Ping timeout: 264 seconds]
feoafka has quit [Quit: feoafka]
athidhep has joined #linux-rockchip
feoafka has joined #linux-rockchip
athidhep has quit [Ping timeout: 255 seconds]
IgorPec has joined #linux-rockchip
<LongChair> stdint: i have ffmpeg / mpp working. and also video output working with mpv
<LongChair> both with drm & opengl now
<stdint> I just offer a way to improve the performance
<LongChair> which is ?
<stdint> LongChair, if you follow the demo, it may not work with a poor performance
<LongChair> you mean the sample i used has poor performance ?
<stdint> maybe, not sure
<stdint> I never use that sample to write my gstreamer plugin
<LongChair> it's hard to see in gst plugin what is different from the sample
<LongChair> stdint: did you check my code ?
<stdint> just a quick view
<LongChair> i just check the rockchipmpp branch of gst
<stdint> if you like, I will
<LongChair> don't really see much difference from my code except all the gst functions
<stdint> it is similar
<stdint> but not the same I think
<LongChair> yeah would be nice if you could have a look and eventually comment what would need to be changed
<stdint> I will if I have the time in a few days
<LongChair> also i had a question, phh mentionned that one of his rk3288 was playing 4k@60 fine on android, and would hardly play 4k@14 on linux
<LongChair> they are supposed to have same kernel
<LongChair> what could explain such a difference
<stdint> I don't think it is the same kernel
<LongChair> that shows that the hardware should be capable ...
<stdint> I didn't remember the android has been updated to kernel 4.4
<LongChair> even if they don't have same kernel .... any idea on what could make such a difference ?
<stdint> the drm driver
<stdint> have you try the hack patch which improve the drm performance?
<LongChair> if that is the one wzyy2 mentionned then yeah
<stdint> yes, that is
<stdint> does it work?
<LongChair> well drm works, but the performance is not good enough for 4k@60 from what i have seen
<stdint> at lease, it is much better than 4k@14fps, right?
<LongChair> on mpv side it doesn't make much diff, as if it can't keep up with framerate, it will drop frames
<LongChair> so it's all jerky
<stdint> I see, ok I would check your code later
<LongChair> even with that patch i seem to be able to play 4K@24 .. but still will depends on vides
<LongChair> videos
<LongChair> omegamoon : got LE built for RK3288 btw, it still requires some cleanup
<LongChair> so next step is to integrate my ffmpeg work within kodi for him
<stdint> LongChair, https://goo.gl/tRXUgv have a try on those video
<stdint> if the bitrate of the video is too high, the hardware can't handle it neither
<LongChair> should all of these videos work ?
<stdint> I think of
<LongChair> stdint: also i had a question on mpp, decoding process is a mix of pushing packets and retrieving frames. in my code the frames retrieving either returns a frame right away or returns that there is no frame.
<LongChair> is there a way to have it block on frame retrieval until there is a frame (eventually with a timeout ?)
<LongChair> because t makes the code loop at very high speed currently
<LongChair> and i'd like to have some block mechanism without having to use sleeps
<stdint> LongChair, poll() of the mpi
<stdint> not the system poll(), there is function to set block operation in mpi
<stdint> a function named poll()
beeno has joined #linux-rockchip
<LongChair> i'll check that
<LongChair> which mpp header is that function in ?
<LongChair> because i don't see it in the mpp headers
<LongChair> stdint: only thing with poll in the name is "poll_task"
<LongChair> but it has params that i don't have
<stdint> LongChair, look at what I did in gstmppdecbufferpool
<stdint> yes it is
<stdint> but if you looks into the api
<stdint> you would find the same thing as the the poll() used in mpi_dec_test
<LongChair> setting that flag will make mpp_frame_get_buffer block until there is a frame ?
<LongChair> err mpi->decode_get_frame
<LongChair> stdint: it can't find MPP_POLL_BLOCK
<stdint> LongChair, yes, it would block in decode_get_frame()
<amstan> swabbles: how's it going?
<LongChair> stdint: i can't find the flag you're uding in mpp / gst : MPP_POLL_BLOCK
<stdint> do you switch to the new mpp?
<stdint> the other branch
IgorPec has quit [Ping timeout: 240 seconds]
<LongChair> yeah can't find it in rockchip_mpp branch or master
<LongChair> linaro@linaro-alip:~/gstreamer-rockchip$ git grep MPP_POLL_BLOCK
<LongChair> gst/rockchipmpp/gstmppdecbufferpool.c: gint block_flag = MPP_POLL_BLOCK;
<LongChair> and there is no entry at all in mpp for this
<LongChair> @stdint ? ^
<stdint> base/mpp_task_impl.cpp
<stdint> look at the for_linux branch of mpp
<stdint> it is the latest branch of mpp
<LongChair> oh that is not the branch i'm running
<LongChair> i suppose i should run that one ?
<LongChair> stdint: swapped to for_linux brnahc to rebuild it
<LongChair> getting build errors, would anything else need to be updated ?
<LongChair> [ 83%] Linking CXX executable h265d_parser_test
<LongChair> collect2: error: ld returned 1 exit status
<LongChair> ../../../../librockchip_mpp.so.1: undefined reference to `VPUClientSendReg'
<LongChair> ../../../../librockchip_mpp.so.1: undefined reference to `VPUClientWaitResult'
<stdint> never meet it
<LongChair> i suppose one of the vpu libs is outdated ?
<LongChair> where can i find the most recent package ?
<LongChair> i have librockchip-vpu0_1.2.2-1_armhf.deb installed
<LongChair> unless cmake needs some arguments to build ...
<stdint> remove them
<stdint> yes, look at the debian rules file
<LongChair> the librockchip-vpu0_1.2.2-1_armhf.deb is the last i can find in the repo
<stdint> well, it is 1.3.0 time now
<LongChair> ok i fixed the buil
<LongChair> +d
<LongChair> stdint: is there any timeout that is configurable for the blocking part ?
<stdint> I can't remember, but I never use it
IgorPec has joined #linux-rockchip
<LongChair> because i added that in my code, but that seems to get very quickly completely blocking .. actually after first frame
<LongChair> maybe it's lacking data, but it will never get fed again ad feeding is done in same thread
<LongChair> i also have a rather high cpu usage at this point even with hw decoding ... so need to investigate that
<stdint> I use two thread to do those job
<stdint> so I don't have this problem
LongWork has joined #linux-rockchip
<LongWork> stdint: well in my case using thread wouldn't change anything
<LongWork> problem is the read / write loop is using cpu unless there is some sort of wait
<LongWork> i don't like to use sleep for that, i prefer stuff like poll, but having it blocking without timeout is not a good idea
<swabbles> amstan: it works, except that I am still getting those messages.
<swabbles> Just not sure what is causing them or what they are about.
<LongWork> i need to check if there is a way to set any timeout there
<amstan> swabbles: what messages?
<swabbles> It happens somewhere during init.
<swabbles> But I can't find anything in /var/log/messages or dmesg.
<amstan> dmesg should have everything since the first console line when booting
<swabbles> One of the messages mentioned something about "monitor"
<swabbles> But I can't find that in dmesg.
<amstan> take a picture?
<swabbles> It is way too fast :(.
<amstan> video
<swabbles> But I can try.
<swabbles> "passed device to netlink monitor"
<swabbles> Seems to be udev related.
<swabbles> Gone now :).
<amstan> why
<swabbles> I think this rootfs had some verbose udev enabled.
<swabbles> But I normally use eudev so I installed that.
matthias_bgg has joined #linux-rockchip
paulk-blaze has joined #linux-rockchip
cnxsoft has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-rockchip
<LongWork> stdint: i checked the mpp code, and it turns out that the poll flag will trigger a condition.wait(), which doesn't have any timeout
<LongWork> the same condition class has a timedwait function
<LongWork> which would allow to have a timeout
<LongWork> so maybe a smart way would be to add another control operation that allows to set the timeout
<phh> LongWork: I didn't say it was 60fps ;), the video I took was 30fps. I'll try a 60fps this evening
<LongWork> ok
<LongWork> seen the link that randy provided above
<LongWork> maybe good to have a few samples to compare
<LongWork> this one http://demo-uhd3d.com/fiche.php?cat=uhd&id=145 has been a good sample for me on amlogic
<LongWork> phh: i'm usually trying these videos : http://demo-uhd3d.com/categorie.php?tag=hevc
<LongWork> if that one plays on 3288 & android then i'm interested
<LongWork> was only able to play a few 24p / 8 bits ones properly up to now
<LongWork> that one plays fine here : http://demo-uhd3d.com/fiche.php?cat=uhd&id=134
beeno has quit [Ping timeout: 260 seconds]
<LongWork> but i didn't have much chance with any other
<LongWork> and then a way to use it (more likely thru an mpi control operation)
<LongWork> and use mCondition->wait / timedwait depending on the control param
beeno has joined #linux-rockchip
<phh> LongWork: lg_chess works fine
<LongWork> so 60 fps ?
<LongWork> in main 10
<phh> mediainfo tells me 59.94 ;)
<LongWork> that is a great news .... well the bad news is I suppose this is on android .... any chance you can try that in gst ?
<LongWork> because either my code suck, or something is wrong on linux :)
<LongWork> possible either ways :p
<phh> LongWork: I've already told you, I can't do 30fps 8bit in gst
<LongWork> ok so something is wrong on linux
<LongWork> and RK3288 is capable which is a good news
<LongWork> probably will be some big hunt to get that properly working on linux though ;)
<LongWork> @stdint @wzyy2 ^^
<LongWork> chess video is some sort of holy grail on most platforms we used.
lkcl has quit [Ping timeout: 240 seconds]
paulk-blaze has quit [Remote host closed the connection]
<LongWork> @phh : btw i have also implemented the opengl dmabuf stuff for mpv and it works allright
nighty has quit [Quit: Disappears in a puff of smoke]
<LongWork> at least for up to 1080p stuff (but mali can't handle 4K)
robogoat has quit [Ping timeout: 260 seconds]
wzyy2 has quit [Ping timeout: 240 seconds]
lkcl has joined #linux-rockchip
beeno has quit [Ping timeout: 240 seconds]
IgorPec2 has joined #linux-rockchip
IgorPec has quit [Ping timeout: 260 seconds]
<LongWork> ayaka: would you accept a PR for that timeout thing in mpp ?
<LongWork> ir add MPP_SET_OUTPUT_BLOCK_TIMEOUT as a control operation ?
<LongWork> another option would have been to use the MPP_SET_OUTPUT_BLOCK param as timeout
<LongWork> it's currently only used as a flag, but the value is an int
<LongWork> ie if it's 0 then no block, otherwise the value passed is the timeout ...
muvlon has joined #linux-rockchip
nighty has joined #linux-rockchip
lkcl has quit [Ping timeout: 268 seconds]
wzyy2 has joined #linux-rockchip
wzyy2 has quit [Read error: Connection reset by peer]
IgorPec has joined #linux-rockchip
IgorPec2 has quit [Ping timeout: 240 seconds]
beeno has joined #linux-rockchip
wzyy2 has joined #linux-rockchip
IgorPec4 has joined #linux-rockchip
IgorPec5 has joined #linux-rockchip
IgorPec4 has quit [Ping timeout: 252 seconds]
muvlon has quit [Ping timeout: 240 seconds]
IgorPec6 has joined #linux-rockchip
IgorPec5 has quit [Ping timeout: 252 seconds]
IgorPec7 has joined #linux-rockchip
IgorPec8 has joined #linux-rockchip
IgorPec6 has quit [Ping timeout: 260 seconds]
wzyy2 has quit [Read error: Connection reset by peer]
wzyy2 has joined #linux-rockchip
wzyy2 has quit [Read error: Connection reset by peer]
IgorPec7 has quit [Ping timeout: 255 seconds]
IgorPec9 has joined #linux-rockchip
IgorPec8 has quit [Ping timeout: 264 seconds]
paulk-blaze has joined #linux-rockchip
paulk-blaze has quit [Quit: Leaving]
wzyy2 has joined #linux-rockchip
wzyy2 has quit [Read error: Connection reset by peer]
wzyy2 has joined #linux-rockchip
wzyy2 has quit [Read error: Connection reset by peer]
IgorPec10 has joined #linux-rockchip
IgorPec9 has quit [Ping timeout: 260 seconds]
Ancient has joined #linux-rockchip
wzyy2 has joined #linux-rockchip
wzyy2 has quit [Read error: Connection reset by peer]
paulk-blaze has joined #linux-rockchip
IgorPec10 has quit [Ping timeout: 252 seconds]
wzyy2 has joined #linux-rockchip
wzyy2 has quit [Read error: Connection reset by peer]
IgorPec10 has joined #linux-rockchip
IgorPec10 has quit [Ping timeout: 264 seconds]
IgorPec10 has joined #linux-rockchip
wzyy2 has joined #linux-rockchip
IgorPec10 has quit [Ping timeout: 240 seconds]
cnxsoft has quit [Quit: cnxsoft]
wzyy2 has quit [Ping timeout: 260 seconds]
lkcl has joined #linux-rockchip
wzyy2 has joined #linux-rockchip
wzyy2 has quit [Ping timeout: 260 seconds]
descend-irc has joined #linux-rockchip
JohnDoe_71Rus has joined #linux-rockchip
IgorPec has quit [Ping timeout: 264 seconds]
<rperier> mmind00: hi, are you aware of a bug for the clk "xin32k" that is provided by the rtc chip on 3288 ?
<rperier> basically, when this clock is used by another component like sdio-pwrseq, the kernel hangs on bootup
<rperier> the hangs is related to this clk
<mmind00> rperier: the only thing I know off, is that we don't have a general clock deferral mechanism for orphan clocks
<rperier> that's probably why you wrote this https://patchwork.kernel.org/patch/7690221/, no ?
<mmind00> rperier: correct ... so far the tsadc was the most prominent issue
<rperier> mhhh
<mmind00> rperier: we were waiting on something sunxi-clock releated, but that may have been resolved in the meantime
<mmind00> rperier: you could ping clock maintainers over on #linux-clk to check what's the state of clock deferral ;-)
<rperier> good idea
<rperier> also, I am not sure. But some of my patches are not received on some ML (like linux-kernel or linux-rockchip). Did you see my series for es8328 ? (the one for 96khz/192khz)
<rperier> that's urgent, that's just to be sure if it's on my side or not :/
<rperier> that's not*
robogoat has joined #linux-rockchip
topi`_ is now known as topi`
lkcl has quit [Ping timeout: 240 seconds]
beeno has quit [Ping timeout: 260 seconds]
<mmind00> rperier: I do see "[PATCH 0/4] ASoC: es828: various improvements"
descend-irc has quit [Quit: Connection closed for inactivity]
paulk-blaze has quit [Quit: Leaving]
<rperier> mmind00: yeah that's it. Ok so it's on the ML then. thanks
lkcl has joined #linux-rockchip
<mmind00> rperier: hmm interestingly enough, your recent patches are not in the linux-rockchip archives: http://lists.infradead.org/pipermail/linux-rockchip/2017-February/thread.html
<mmind00> rperier: so maybe you should talk to your mail-server admin to see if they got rejected somehow
<LongChair> phh: did some further testing ... looks like X11 is getting mad when i display video
<phh> using X or drm?
<LongChair> on 1080p movie even if using drm the X process is staling one core
<LongChair> i'm wodnering if that is not the perf issue we're having
<LongChair> and it doesn't really matter wether i use opengl or drm, same behavior with both
<LongChair> typical top during video playback :
<LongChair> 16378 linaro 20 0 73232 20588 15308 S 6.6 1.0 1:26.14 lxterminal
<LongChair> 20149 root 20 0 356984 226096 59076 S 52.0 11.0 0:05.87 mpv
<LongChair> 1352 root 20 0 435876 309824 168476 R 110.7 15.0 43:53.55 X
<LongChair> 110% for X
<LongChair> 52 for mpv
<LongChair> doesn't make much sense to me
beeno has joined #linux-rockchip
<LongChair> maybe i'm having the wrong xserver
<LongChair> i recall wzyy2 telling me to install some package ... but not sure which one it was
<LongChair> should have written this down
<LongChair> like the xserver-xorg-dev_1.18.4-1_armhf.deb one ?
<mmind00> rperier: although the alsa-devel list did like your mails, so only infradead seems not to, but hopefully there should be some evidence in your collabora mailserver logs on what it didn't like
lkcl has quit [Ping timeout: 260 seconds]
wzyy2 has joined #linux-rockchip
wzyy2 has quit [Ping timeout: 255 seconds]
beeno has quit [Ping timeout: 240 seconds]
indiana_ has joined #linux-rockchip
<indiana_> I had a question not sure if i can ask here?
<LongChair> you'll never know if you don't ask ... :)
paulk-collins has joined #linux-rockchip
<indiana_> I would like to know how to make a flashable rom. I have Several tx5pro boxes that i want to clone.
<indiana_> I see people uploading custom roms on freaktab with there launchers installed, programs installed ect. I want to do the same.
<LongChair> i have no idea ... maybe someone else can help
indiana_ has quit [Ping timeout: 260 seconds]
LongChair has quit [Quit: LongChair]
LongWork is now known as LongChair
paulk-collins has quit [Quit: Leaving]
LongChair1 has joined #linux-rockchip
zzarr has joined #linux-rockchip
JohnDoe_71Rus has quit [Quit: KVIrc 4.9.2 Aria http://www.kvirc.net/]
nighty has quit [Quit: Disappears in a puff of smoke]