ChanServ changed the topic of #linux-rockchip to: Rockchip development discussion | IRC log http://irclog.whitequark.org/linux-rockchip | Community GH https://github.com/linux-rockchip | Rockchip GH https://github.com/rockchip-linux | ML https://groups.google.com/group/linux-rockchip
lurchi__ is now known as lurchi_
lurchi_ is now known as lurchi__
lurchi__ is now known as lurchi_
vstehle has quit [Ping timeout: 240 seconds]
afaerber has quit [Remote host closed the connection]
kaspter has joined #linux-rockchip
kaspter1 has joined #linux-rockchip
nighty- has joined #linux-rockchip
kaspter has quit [Ping timeout: 240 seconds]
kaspter1 is now known as kaspter
phinxy has quit [Read error: Connection reset by peer]
m0nt3 has quit [Ping timeout: 260 seconds]
m0nt3 has joined #linux-rockchip
libv_ has joined #linux-rockchip
libv has quit [Ping timeout: 260 seconds]
cnxsoft has joined #linux-rockchip
paulk-gagarine-s has joined #linux-rockchip
paulk-gagarine has quit [Ping timeout: 252 seconds]
lurchi_ is now known as lurchi__
libv_ is now known as libv
aalm has joined #linux-rockchip
m0nt3 has quit [Ping timeout: 252 seconds]
m0nt3 has joined #linux-rockchip
lurchi_ has joined #linux-rockchip
lurchi__ has quit [Ping timeout: 264 seconds]
m0nt3 has quit [Ping timeout: 260 seconds]
vstehle has joined #linux-rockchip
m0nt3 has joined #linux-rockchip
akaizen has quit [Ping timeout: 260 seconds]
akaizen has joined #linux-rockchip
cnxsoft has quit [Ping timeout: 240 seconds]
libv_ has joined #linux-rockchip
libv has quit [Ping timeout: 260 seconds]
cnxsoft has joined #linux-rockchip
<LongChair> stdint: u around ? :)
<stdint> en
<LongChair> i have a question regarding video colorspaces
<LongChair> is there a way to set the display colorspace that is given by the video ?
<stdint> the decoder won't care about that
<LongChair> yes
<LongChair> the decoder will though allow to get the video colorspace
<stdint> if you want to set the colorspace of the video input for those display system
<LongChair> is there an API to do so ?
<stdint> I won't suggest to use the decoder to do those job
<LongChair> yeah giving that to display system is good
<LongChair> but i haven't seen any way to do that with DRM. is there any ?
<stdint> the colorspace could be get from more early stage
<LongChair> ok, but how do you pass it to display system ? which API allows to do that ?
<stdint> in my memory, the colorspace is binding to pixel format at drm system
<LongChair> hmmm, I have a video that had a bt709 colorspace and it plays very dark
<LongChair> i don't think there is any bt709 pixel format in drm
libv_ has quit [Ping timeout: 260 seconds]
libv has joined #linux-rockchip
<LongChair> stdint: i know opengl has a few extensions for that .. but didn't see that for direct DRM usage with oberlays
<stdint> I don't think the drm having such thing either
<stdint> although the vop supports it, but I don't think there is a way to set it under the current drm api
<LongChair> ok
<LongChair> from the little seach i made, the only way DRM API provides to set such things is to use the atomic layer properties
<LongChair> but if it's not implemented
ayaka has quit [Ping timeout: 255 seconds]
moneymaker has quit [Ping timeout: 240 seconds]
robogoat has quit [Ping timeout: 240 seconds]
cosm has quit [Remote host closed the connection]
moneymaker has joined #linux-rockchip
ventosus has quit [Ping timeout: 240 seconds]
beeble has quit [Ping timeout: 240 seconds]
beeble has joined #linux-rockchip
ventosus has joined #linux-rockchip
eebrah has quit [Ping timeout: 255 seconds]
cosm has joined #linux-rockchip
eebrah has joined #linux-rockchip
ayaka has joined #linux-rockchip
robogoat has joined #linux-rockchip
m0nt3 has quit [Ping timeout: 252 seconds]
uyhoang has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
matthias_bgg has quit [Remote host closed the connection]
kloczek has quit [Remote host closed the connection]
_whitelogger has joined #linux-rockchip
kloczek has joined #linux-rockchip
phinxy has joined #linux-rockchip
nighty- has quit [Quit: Disappears in a puff of smoke]
pfeerick has quit [Ping timeout: 252 seconds]
pfeerick has joined #linux-rockchip
uyhoang has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
libv_ has joined #linux-rockchip
pfeerick has quit [Ping timeout: 240 seconds]
libv has quit [Ping timeout: 260 seconds]
libv_ is now known as libv
pfeerick has joined #linux-rockchip
nasuga has joined #linux-rockchip
kaspter has quit [Quit: kaspter]
kaspter has joined #linux-rockchip
nighty- has joined #linux-rockchip
nasuga has quit [Ping timeout: 260 seconds]
libv has quit [Ping timeout: 260 seconds]
libv has joined #linux-rockchip
LargePrime has quit [Remote host closed the connection]
LargePrime has joined #linux-rockchip
<LongWork> @stdint @ayaka : I also have noticed something that i never noticed before. it seems when i compare the ffmpeg sw decoding to the hw decoding, that it will lack one frame most of the time.
MoeIcenowy has quit [Ping timeout: 248 seconds]
<LongWork> i also have added logs to check what was going on, and i can see that one frame is skipped just at the end of my video
<LongWork> in that case the frame having the pts 371 is never returned
<LongWork> goes from 370 to 372
aalm has quit [Ping timeout: 248 seconds]
<LongWork> Would this be a known issue ?
MoeIcenowy has joined #linux-rockchip
kaspter has quit [Quit: kaspter]
nasuga has joined #linux-rockchip
nighty-_ has joined #linux-rockchip
cnxsoft has quit [Quit: cnxsoft]
wadim_ has quit [Remote host closed the connection]
vagrantc has joined #linux-rockchip
<ayaka> LongWork, which video?
<Ke> would rk3399 chromebooks boot from SD, if you emptied the spi flash and the emmc?
<Ke> or rk3288?
<phh> well rk3288 chip does that
<phh> perhaps it's been disabled as a security protection on chromebooks though
<Ke> phh: yes, that's exactly, what I am asking
<Ke> paulk-gagarine-s might know
<paulk-gagarine-s> probably not
phinxy has quit [Read error: Connection reset by peer]
<Ke> thanks
Jagan has joined #linux-rockchip
<Jagan> Hi, can anyone confirm was this the proper branch for mali working on rk3288
<Jagan> I observed a failure
<Jagan> [ 1.838039] mali ffa30000.gpu: Continuing without Mali clock control
<Jagan> [ 1.845265] mali ffa30000.gpu: Failed kbase_common_device_init
<phh> Jagan: now mali has its dts in mainline kernel, and the closed source driver from ARM is buildable out-of-tree
<phh> https://github.com/rockchip-linux/rockchip_forwardports I guess that would be the right link
<phh> and since you need matching userspace, that would be https://github.com/rockchip-linux/libmali
* vagrantc didn't see any binary blobs for rk3399 ...
<vagrantc> or rather, mali t8* on the rk3399 in the firefly
<Jagan> Yeah for uspace I've buildroot with mali libraries
<beeble> works with gles and opencl for me
<vagrantc> i was looking at the arm developer site...
<vagrantc> so i guess i didn't know where to look :)
<phh> it would be so much better to have ARM do public release for every releases they make...
<beeble> usb start
<beeble> ups
<beeble> wrong window
Jagan has quit [Ping timeout: 260 seconds]
aalm has joined #linux-rockchip
<amstan> phh, Ke: yes, the power rails for the sd card has to get enabled by the firmware first
<amstan> so it's a chicken and egg problem if you try to do that
<Ke> I would guess just getting the power there should be trivial to hack though
<Ke> but sure, that would be a hw mod
<amstan> why don't you continue to use the spi flash?
<amstan> you can use something like this: https://gist.github.com/jcs/4bf59314d604538a5098
<phh> well, perhaps the pmic can be reconfigured
<Ke> just a hypothetical question
<amstan> it's not necessarly via the pmic
<amstan> the 3399 chromebooks don't even have pmics, it's all through the ec
<amstan> but something as simple as the sd card power is probably just a pin on the ap
<amstan> Ke: what are you trying to find out?
<phh> mmm, sdcard power is not simple, you might switch to 1.8 and 3.3
<amstan> 2 pins probably then
<Ke> amstan: exactly what I asked
<phh> amstan: according to dts, sd is power supplied by the pmic on veyron
<Ke> anyway I already have libreboot on my C201, though I would be interested in switching that to u-boot eventually
<amstan> phh: that's correct on veyron
<phh> is there other rk3288 platform for chromebook?
<amstan> no
<phh> ok
<amstan> veyron is the only chromebook design with 3288, and they all use rk808
<Ke> though I guess I can use the u-boot, once I start using the Kevin
<phh> I'll need to check the ec design on rk3399 chromebooks, I'm curious how they do regulation
<Ke> is there some other rk3399 chromebook?
<amstan> not yet
<phh> isn't the asus one released yet?
<amstan> i don't know actually, maybe some countries have it already
<phh> seems not
<amstan> phh: yep, 2 pins, one pwren, the other picks between 1.8V and 3.3V
<amstan> goes to the 3399 directly
ayufan has quit [Remote host closed the connection]
ayufan has joined #linux-rockchip
<amstan> oh, 3rd pin for the other rail of the sd card
<amstan> Ke: anyway, short answer is no, on 3399 you can't do this
<Ke> on rk3399 yes, on Kevin no, right?
<amstan> yep
<amstan> i meant 3399 chromebooks
<amstan> just curious what you are trying to do though, is it just so you have an easier time trying various firmwares?
<Ke> that was one aspect, but right now I am not doing anything
<Ke> besides ordering external flashing equipment to figure out whether my rk3399 firefly is really broken
<amstan> external flashing? i didn't think there was a way to brick the firefly
<Ke> and then I will wait, until linux/u-boot/libreboot has sufficient support for Kevin to use it in daily life
<amstan> you always have the usb recovery maskrom stuff available
<amstan> kevin's stock firmware can boot normal linux distributions right now: https://archlinuxarm.org/platforms/armv8/rockchip/samsung-chromebook-plus
<phh> amstan: if I understood correctly, it's a bit annoying, because the pins are not soldered or anything. though they are exposed
<Ke> sure, if you have divine mechanical hands
<phh> Ke: it's the pads next to the emmc?
<amstan> Ke: ah, you don't like shorting the emmc pads?
<Ke> I probably partially broke the board trying to boot it into maskrom mode
<amstan> aww
<amstan> phh: what do you mean?
<phh> amstan: there is no jumper or switch, just exposed pad
<Ke> seeing how long you have to hold the pads while connecting the power, I recommend soldering some wires to the pads, if you want to go that way
<Ke> but really first recommendation should really be the spi boot for recovery
<phh> amstan: I wish coreboot support uefi, this way we could really boot any armv8 distrib
<phh> but well
<Ke> I don't know what state the emmc is in, but the SoC thinks it contains valid stuff
<Ke> but in maskrom mode anything I read from it is just 0xfffff
<amstan> phh: there's a "legacy" boot slot on the chromebook firmware, you can have a payload(a bootloader) that does whatever you want, you can flash that without even removing the write protect
<amstan> but it's a lot more work
<phh> oh, having a flashable payload is nice, i didn't know it was the case (though I doubt I'd do anything with it)
<amstan> it's what seabios resides in on the intel systems (where you can do Ctrl+L)
<Ke> I guess grub-efi one amv8 might be nice so I could decrypt the rootfs from bootloader instead of the initramfs
<Ke> u-boot is awesome, but definitely is has less features than grub
<phh> https://www.minocacorp.com/doc/1375/file/uefi/plat/veyron/ looks like there is an uefi implementation for veyron...
<amstan> Ke: why do you want to have your rootfs encrypted (as opposed to just /home)?
<Ke> why not?
<amstan> well it's really annoying to setup for one
<Ke> also it's more flexible in space allocation
<Ke> it's the kind of setup once, use forever thing
<Ke> touching anything that is not x86 is way harder than doing encrypted rootfs
<phh> oh, u-boot implements uefi now
<amstan> i've considered it, but given how fragile my system is right now (without encryption)
<amstan> like i've had to boot from other sources many times
<amstan> adding encryption in there is just asking for more headake
<Ke> amstan: also, I use btrfs, it really sucks for small filesystems
<phh> Ke: can't you cipher only part of a partition with btrfs?
<Ke> no
<Ke> actually many key btrfs devs were vehemently against implementing pseudo block device crypto in btrfs
<phh> you might want to use ext4crypt then
<Ke> I am very well aware of the options
<phh> ok :)
<Ke> oh there is a patch to support file level crypto on btrfs, but it's not in mainline yet either
nasuga has quit [Ping timeout: 246 seconds]
<Ke> I guess that would have been more like what you were referring to
<Ke> I am a strong believer in block device level crypto, it's very difficult to assess what you are leaking on file based crypto
<Ke> though I am leaking a lot of data with discard passthrough on my crypto devices
lkcl has quit [Ping timeout: 240 seconds]
vagrantc has quit [Quit: leaving]
lkcl has joined #linux-rockchip
afaerber has joined #linux-rockchip
nasuga has joined #linux-rockchip
gnufan has left #linux-rockchip [#linux-rockchip]
aalm has quit [Ping timeout: 240 seconds]
_whitelogger has joined #linux-rockchip
mrueg has quit [Remote host closed the connection]
cyteen has quit [Ping timeout: 248 seconds]
mrueg has joined #linux-rockchip
vagrantc has joined #linux-rockchip
vagrantc has quit [Changing host]
vagrantc has joined #linux-rockchip
kloczek_ has joined #linux-rockchip
kloczek has quit [Ping timeout: 255 seconds]
kloczek_ is now known as kloczek
vstehle has quit [Ping timeout: 252 seconds]