<naobsd>
cosm: that source may not work on your device. if you want Radxa Rock, please ask me
<naobsd>
cosm: latest kernel source should support hw cursor (I just checked code, not tried on Linux)
<naobsd>
cosm: Rockchip official gcc is "gcc version 4.6.x-google 20120106 (prerelease)" in Android 4.2/4.4 tree (prebuilts/gcc/linux-x86/arm/arm-eabi-4.6)
cnxsoft has quit [Ping timeout: 265 seconds]
_massi_ has joined #linux-rockchip
ferric_ has joined #linux-rockchip
ferric has quit [Read error: Connection reset by peer]
cnxsoft has joined #linux-rockchip
rz2k has joined #linux-rockchip
irsol_ has joined #linux-rockchip
irsol has quit [Ping timeout: 252 seconds]
irsol_ has quit [Changing host]
irsol_ has joined #linux-rockchip
irsol_ is now known as irsol
cnxsoft has quit [Ping timeout: 265 seconds]
Astralix has quit [*.net *.split]
ganbold has quit [*.net *.split]
mrueg has quit [*.net *.split]
RaYmAn has quit [*.net *.split]
ferric_ has quit [*.net *.split]
cosm has quit [*.net *.split]
markvandenborre has quit [*.net *.split]
ssvb has quit [*.net *.split]
pbacon has quit [*.net *.split]
moofree has quit [*.net *.split]
jcarlos has quit [*.net *.split]
itdaniher has quit [*.net *.split]
ChanServ has quit [*.net *.split]
naobsd has quit [*.net *.split]
FergusL has quit [*.net *.split]
rperier has quit [*.net *.split]
irsol has quit [*.net *.split]
rz2k has quit [*.net *.split]
anatoly has quit [*.net *.split]
hramrach has quit [*.net *.split]
RayFlower has quit [*.net *.split]
npcomp has quit [*.net *.split]
MadSpark has quit [*.net *.split]
_massi_ has quit [*.net *.split]
Tsvetan has quit [*.net *.split]
else- has quit [*.net *.split]
valdur55 has quit [*.net *.split]
VargaD has quit [*.net *.split]
mac- has quit [*.net *.split]
_hipboi_ has quit [*.net *.split]
zoobab has quit [*.net *.split]
phh has quit [*.net *.split]
mnemoc has quit [*.net *.split]
honx has quit [*.net *.split]
irsol has joined #linux-rockchip
cosm has joined #linux-rockchip
mrueg has joined #linux-rockchip
anatoly has joined #linux-rockchip
pbacon has joined #linux-rockchip
ChanServ has joined #linux-rockchip
ferric_ has joined #linux-rockchip
ssvb has joined #linux-rockchip
jcarlos has joined #linux-rockchip
MadSpark has joined #linux-rockchip
RaYmAn has joined #linux-rockchip
rz2k has joined #linux-rockchip
naobsd has joined #linux-rockchip
_hipboi_ has joined #linux-rockchip
mnemoc has joined #linux-rockchip
Tsvetan has joined #linux-rockchip
itdaniher has joined #linux-rockchip
zoobab has joined #linux-rockchip
honx has joined #linux-rockchip
valdur55 has joined #linux-rockchip
markvandenborre has joined #linux-rockchip
moofree has joined #linux-rockchip
_massi_ has joined #linux-rockchip
FergusL has joined #linux-rockchip
VargaD has joined #linux-rockchip
ganbold has joined #linux-rockchip
else- has joined #linux-rockchip
rperier has joined #linux-rockchip
hramrach has joined #linux-rockchip
Astralix has joined #linux-rockchip
mac- has joined #linux-rockchip
phh has joined #linux-rockchip
RayFlower has joined #linux-rockchip
npcomp has joined #linux-rockchip
<cosm>
naobsd: if different versions of gcc produce code that behaves differently, it's a bug
<cosm>
probably some wrong assumption in manual assembly code
io has joined #linux-rockchip
io is now known as Guest55545
<cosm>
naobsd: it might be worth trying to cherry-pick patches one by one for stuff that's not already supported on that kernel
<cosm>
naobsd: as far as I remember, only the version I've forked from was working on my device
nighty-_ has joined #linux-rockchip
npcomp has quit [Ping timeout: 240 seconds]
Guest55545 has quit [Ping timeout: 240 seconds]
npcomp has joined #linux-rockchip
cnxsoft has joined #linux-rockchip
RayFlower has quit [Ping timeout: 240 seconds]
ganbold_ has joined #linux-rockchip
cosm has quit [Ping timeout: 250 seconds]
cosm has joined #linux-rockchip
cosm has quit [Ping timeout: 258 seconds]
rz2k has quit []
cosm has joined #linux-rockchip
npcomp has quit [Ping timeout: 255 seconds]
npcomp has joined #linux-rockchip
npcomp has quit [Ping timeout: 258 seconds]
npcomp has joined #linux-rockchip
tonikasch has joined #linux-rockchip
cnxsoft has quit [Remote host closed the connection]
FreezingCold has joined #linux-rockchip
GriefNorth has joined #linux-rockchip
m1r has joined #linux-rockchip
ganbold_ has quit [Remote host closed the connection]
rz2k has joined #linux-rockchip
ganbold_ has joined #linux-rockchip
bgal has joined #linux-rockchip
tonikasch has quit [Quit: Bye!]
cosm has quit [Ping timeout: 252 seconds]
bgal has quit [Ping timeout: 245 seconds]
ganbold_ has quit [Ping timeout: 264 seconds]
RayFlower has joined #linux-rockchip
FreezingCold has quit [Ping timeout: 252 seconds]
bgal has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
FreezingCold has joined #linux-rockchip
RayFlower has quit [Read error: Connection reset by peer]
RayFlower has joined #linux-rockchip
cosm has joined #linux-rockchip
rz2k has quit [Read error: Connection reset by peer]
_massi_ has quit [Quit: Leaving]
cosm has quit [Ping timeout: 240 seconds]
bgal has quit [Ping timeout: 240 seconds]
m1r has quit [Ping timeout: 264 seconds]
cosm has joined #linux-rockchip
npcomp has quit [Ping timeout: 240 seconds]
<cosm>
ok, so my new RK3188 dongle was delivered today
<cosm>
this one uses a 32bit wide memory bus
npcomp has joined #linux-rockchip
<cosm>
ssvb: it has roughly twice the memory bandwidth of the other one
<ssvb>
cosm: heh, using 16bit memory bus is really insane, that's a performance disaster
* ssvb
wonders how many rockchip based devices are affected by this
<ssvb>
cosm: maybe you still can increase the dram clock speed from 360mhz to something higher in that tablet
<cosm>
yeah, I think the Android kernel uses 400 MHz
<cosm>
even so, 10%, maybe 20% with overclocking isn't a big deal
<ssvb>
allwinner based devices can run dram at up to 480mhz
<cosm>
but I got bored fixing small things for my board before I even got it to successfully boot
<naobsd>
I have some other RK3x boards, I also want to run my own kernel compiled from source
<naobsd>
but my free time is very few, so I decided to use RR at first because I don't need to use my time to find out pin configuration etc ;)
<naobsd>
I'll try other boards when I can get more time
<naobsd>
cosm: btw, about your fbturbo, is video layer YUV?
<cosm>
yes
<cosm>
well, you can also set it to various RGB configurations, but video players use YUV so that's what's implemented for XV
<naobsd>
we can skip color space conversion? good!
<naobsd>
ah
<naobsd>
it's written in README.md ;)
<cosm>
yeah, it's a bit faster than X11 even without doing any resizing
<cosm>
I'm going to push a few updates tonight
<naobsd>
really good :)
* tonikasch
mmmm, i'll contact google again regarding that hantro video decoder&encoder... let's see if this gets resolved soon
<naobsd>
cosm: when you have a time and want to get Radxa Rock, please ask me :)
<tonikasch>
naobsd, cosm: do you know if video encoder/decoder is yet supported under rkchrome tree?
<tonikasch>
I ask just in case... because I'm writing to google on this as they promised to answer when they would have more information
<cosm>
tonikasch: I don't know, sorry
<tonikasch>
no problem
<tonikasch>
so I send the email, ok
<cosm>
tonikasch: I'm not really sure what's the story, are they looking at releasing the source code for the driver?
cosm has quit [Quit: Leaving]
<tonikasch>
yes
<tonikasch>
well... the fact is that google produces it, verisillicon licenses it, rockchip produces the soc with this integrated, final vendors mount the soc with some other components...
<naobsd>
there are some code about vpu and vcodec(this replaces vpu code) in rkchrome
<tonikasch>
:O
<naobsd>
I don't know how it works
<tonikasch>
naobsd ok, i'll dig into it
<tonikasch>
:D thanks
FreezingCold has joined #linux-rockchip
<naobsd>
there is vpu_service.c and vcodec_service.c under arch/arm/mach-rockchip/
<naobsd>
I guess former is same as 3.0, but I didn't check them
<tonikasch>
mmm, I see, so perhaps code is more complete now, nearer the sources they have
<ssvb>
naobsd, cosm: also I wonder what is the status of the kernel? are the ioctls for handling overlays, hardware cursor and the 2d engine stable enough between kernel releases?
<cosm>
ssvb: In the version I'm using, I had to patch up pretty much all of those things because of horrible bugs
<cosm>
ssvb: and I also had to add a few ioctls
valdur55 has quit [Remote host closed the connection]
<cosm>
ssvb: yeah, there's no more tearing in the test videos
<ssvb>
cosm: for the new ioctls, can we have them defined with the use of _IO/_IOR/_IOW/_IOWR macros?
<cosm>
ssvb: we could, but I was actually being consistent with the other macros used in those drivers :D
<cosm>
*other ioctl definitions
<ssvb>
cosm: something like introducing a new ioctl number by incrementing the last one by 1?
<cosm>
ssvb: yes
<ssvb>
well, that's exactly the thing that should *not* be done
<ssvb>
because if rockchip releases a new kernel and adds a bunch of new ioctls, then they are very likely to clash with yours
<ssvb>
and we end up in a horrible mess
<cosm>
good point
<ssvb>
additionally, the _IO/_IOR/_IOW/_IOWR macros are much safer because they encode the information about input/output arguments of the ioctl
<cosm>
for some, for example hardware cursor stuff, I've just reused their ioctls from older chips
<cosm>
I think those should be fine
<naobsd>
probably latest rockchip kernel still has horrible bugs
<cosm>
and I know about those macros, but they're not used anywhere in rockchip drivers, that's why I've said I'm just being consistent
<cosm>
ok, maybe that's not a good enough reason :D
<naobsd>
if my memory is correct, Rockchip did major changes around fb code some times
<naobsd>
conflict should be avoided if possible, but Rockchip will not care about community code
<naobsd>
and Rockchip will not care compatibility for their own old code ;) (just my guessing)
<cosm>
I get the impression their engineers are really rushed to write code that works *now* and don't really have time for anything else
<naobsd>
cosm: totally agree
<ssvb>
naobsd: yes, still there are and will be some rk kernel forks around, and it would be not very nice if trying to use some ioctl will oops them or fail in some other nasty way
<naobsd>
ssvb: yes
<cosm>
hehe, one of my patches actually makes the fb driver return -NOIOCTLCMD (as opposed to 0) for unsupported ioctls
<cosm>
if that one doesn't get merged in other forks, it could become a real problem to detect missing features
<naobsd>
there are several forks, they don't keep history, I already gave up to refer them
<ssvb>
the space of possible 32-bit ioctls numbers is not too large, but still the collision is not very likely if we try to move the new ioctls away from the current rockchip ioctl numbers
<cosm>
ssvb: yeah, now that you brought that up, I think it's something we should do
<naobsd>
there are many forks which did not use 'fork' button on github...
<cosm>
naobsd: it sounds like you've been around this scene for longer than I have
<cosm>
naobsd: why is almost nobody merging patches?
<cosm>
naobsd: I mean from other forks
<cosm>
naobsd: it's really, really fragmented
<ssvb>
cosm: adding a special 'identification' ioctl may help, it can return some magic signature and the api version number to be sure that we don't mistake it with the other forks
<cosm>
ssvb: yes, that sounds like a good idea for the framebuffer driver
<naobsd>
cosm: there was no common/base source for Rockchip devices. unlike sunxi, board specific code such as pin config is hardcoded.
<naobsd>
cosm: and there is no information such as pin config for all Rockchip devices.
<naobsd>
cosm: at first, people need to care about code for his own device
<cosm>
naobsd: I see
<naobsd>
cosm: actually some people is working to make his code runnable on other devices
<cosm>
naobsd: but it would be so much easier if a config for a board wouldn't be in fork a, support for the wifi adapter in fork b and so on
<cosm>
naobsd: is there any serious effort to clean up this stuff for merging upstream?
<naobsd>
cosm: Astralix and mmind (and maybe other few people) is doing mainlining
<cosm>
naobsd: Oh cool. Do they use a mailing list or something? And do they have a repository?
<naobsd>
there are some members in linux-rockchip organization on github, but it's not working community/organization
<naobsd>
repository in linux-rockchip at github it was just collection very recently some people pushing code into
<naobsd>
sorry
<naobsd>
repositories in linux-rockchip at github were just collection and my personal branches. but very recently some people pushing code/make pull request for linux-rockchip
<naobsd>
btw, I'm not leader of linux-rockchip or something like that
<naobsd>
I'm just a person using linux-rockchip organization on github
<naobsd>
cosm: I'm not active developer. I don't know well about communities maintaining their own forks
<cosm>
naobsd: thanks for the links
<cosm>
I see
<naobsd>
cosm: if you want to use github/linux-rockchip, I can add you as member
<cosm>
thanks, but I'm ok for now
<cosm>
I guess I might want to do that if other people start sending me more generic patches