vagrantc has quit [Quit: leaving]
<
stdint>
phh, yes, with the gstreamer it could work on Linux
<
stdint>
the that driver is not a drm driver anyway
leah2 has quit [Ping timeout: 260 seconds]
geekerlw has joined #linux-rockchip
cnxsoft has joined #linux-rockchip
leah2 has joined #linux-rockchip
akaizen has quit [Ping timeout: 264 seconds]
paulk-collins has quit [Ping timeout: 250 seconds]
paulk-collins has joined #linux-rockchip
Gh0stInTheShell has quit [Quit: leaving]
randy_ has joined #linux-rockchip
stdint has quit [Read error: Connection reset by peer]
randy_ is now known as stdint
geekerlw has quit [Quit: Page closed]
muvlon has quit [Ping timeout: 258 seconds]
muvlon has joined #linux-rockchip
cnxsoft1 has joined #linux-rockchip
cnxsoft has quit [Ping timeout: 248 seconds]
cnxsoft1 is now known as cnxsoft
muvlon has quit [Quit: Leaving]
<
stdint>
LongWork, the benchmark of 4k rendering is not correct I told you yesterday
<
stdint>
it is about 12~15 fps in rk3288
<
LongWork>
that doesn't sound great
<
LongWork>
is that using GPU ?
<
LongWork>
or VPO ?
<
LongWork>
@stdint : basically which API usage these figures correspond to ?
<
stdint>
LongWork, EGL, all the video are rendered through GPU
<
LongWork>
is that using zerocopy ?
<
stdint>
the drm is still fine and benchmark I told you yesterday is correct
<
stdint>
LongWork, yes
<
LongWork>
so there is no hope to achieve 60 fps there right ?
<
LongWork>
i thought it was possible using VPO instead of GPU
<
stdint>
LongWork, no hope with GPU. but It is possible with VOP
<
stdint>
because the limit in PCB design, I could only confirm that I would achieve 30fps in 4K output
<
LongWork>
is the VOP rendering available with vaapi lib ?
<
stdint>
yes, it is just standard DRM driver
<
stdint>
the Intel seems to remove all the video rendering output from VA-API in the future
libv_ has joined #linux-rockchip
libv has quit [Ping timeout: 250 seconds]
paulk-collins_ has joined #linux-rockchip
paulk-collins__ has joined #linux-rockchip
paulk-collins has quit [Ping timeout: 252 seconds]
paulk-collins_ has quit [Ping timeout: 248 seconds]
paulk-collins_ has joined #linux-rockchip
paulk-collins__ has quit [Ping timeout: 256 seconds]
liuqs has quit [Quit: Page closed]
vagrantc has joined #linux-rockchip
<
paulk-collins_>
stdint, are you familiar with the firefly rk3399 board?
cnxsoft has quit [Quit: cnxsoft]
<
ayaka>
paulk-collins_, yes, I have been told this plan a few days ago
<
ayaka>
it seems that the DP(not eDP) would be export in that board
<
paulk-collins_>
nice!
<
paulk-collins_>
ayaka, any chance you know about u-boot support?
<
ayaka>
paulk-collins_, the bootloader at arm64 is a little complicated
<
ayaka>
there is a arm firmware, but it is open source
<
paulk-collins_>
ayaka, right, I'm familiar with it
<
paulk-collins_>
ATF
<
paulk-collins_>
ayaka, does it use coreboot?
<
ayaka>
paulk-collins_, coreboard is used for chromium book I think
<
ayaka>
there is a u-boot for Linux, I have used it before
<
ayaka>
but I didn't hear any upstream support beginning for rk3399
<
ayaka>
as the Linux project is just starting and I am not in charge of that
<
ayaka>
but I really worry the quality of that
<
paulk-collins_>
ayaka, ah ouch
<
paulk-collins_>
I see
<
paulk-collins_>
I hope chromebooks will help
<
paulk-collins_>
It'll probably be easier when we have the schematics
<
ayaka>
what I found recently is that the patches from chromebooks won't be merged into internal kernel asap
<
ayaka>
it would be merged only when it is necessary
<
ayaka>
it give me a huge problems with android video driver a few weeks before
<
paulk-collins_>
ah too bad
<
paulk-collins_>
ok we'll see how it goes
<
paulk-collins_>
the board won't be released tomorrow anyway
<
ayaka>
I think I would be notified the schedule
<
ayaka>
and the firefly rk3399 is really not on the recently schedule
<
paulk-collins_>
okay then
<
paulk-collins_>
let's see later
* vagrantc
needs to dig out the veyron-speedy and do some updates and hope things just mangically work now
<
paulk-collins_>
sure
<
paulk-collins_>
I was told of a fix for usb with ath9k_htc
twink0r_ has joined #linux-rockchip
<
vagrantc>
oh, that would be great
<
paulk-collins_>
something to do with some specific kinds of transfers
<
paulk-collins_>
chan->ep_type == USB_ENDPOINT_XFER_ISOC
<
paulk-collins_>
chan->ep_type == USB_ENDPOINT_XFER_INT
<
paulk-collins_>
and then wire_frame is dwc2_hcd_get_frame_number(hsotg)
<
paulk-collins_>
and some test is inverted
<
paulk-collins_>
I hope it will fit for mainline
<
vagrantc>
a bug in the driver, or just .dts ?
<
ayaka>
but recently the mmc driver is broken, I can't boot the system anymore
<
vagrantc>
doh. i've had the bug even on x86, so obviously not in the .dts :)
twink0r has quit [Quit: GOT RL?]
twink0r_ is now known as twink0r
twink0r has quit [Quit: GOT RL?]
twink0r has joined #linux-rockchip
<
paulk-collins_>
vagrantc, it's in the usb driver
vagrantc has quit [Quit: leaving]
scelestic has quit [Read error: Connection reset by peer]
paulk-collins_ is now known as paulk-collins
paulk-collins has quit [Quit: Leaving]
paulk-collins has joined #linux-rockchip
scelestic has joined #linux-rockchip
libv_ has quit [Ping timeout: 260 seconds]
libv has joined #linux-rockchip
libv has quit [Ping timeout: 258 seconds]
libv has joined #linux-rockchip
libv__ has joined #linux-rockchip
libv has quit [Ping timeout: 256 seconds]
libv__ has quit [Ping timeout: 264 seconds]
libv has joined #linux-rockchip
libv_ has joined #linux-rockchip
libv has quit [Ping timeout: 264 seconds]
libv_ has quit [Ping timeout: 264 seconds]
libv has joined #linux-rockchip