<cm8>
they simply differ too much from one to another, unfortunately
<cosm>
I need to take a closer look at how that's supposed to work, maybe it doesn't necessarily need a kernel patch
<cosm>
I think it's a bit insane to approach it this way :), but if I can tweak the userspace driver to work with it, it's better
<cm8>
you mean you could use that ovl mgr, toggling states with fbturbo driver?
<cm8>
if only documentation by rockchip would not be soo sparse..
<cosm>
I've actually found this FB/LCDC code to be quite ok to understand and use with no documentation
<cosm>
I just didn't have that much time to work on it
<cm8>
yeah, but not being consistent you'd have to code for different cases in the userspace driver, i.e. if you want to keep using it with the older kver without that ovl mgr
<cm8>
even a Changelog by Rockchip would help and make life much easier, and if it'd just roughly list the spots they worked on and overhauled..
<cosm>
it's annoying that they break functionality provided to the userspace, yes
<cosm>
the mainline kernel basically *never* does that
<cm8>
yep
<cosm>
anyway, I get the feeling this switching is going to be broken in interesting ways
<cosm>
in which case, well, I'll port my patch to this kernel as well
<cm8>
and if they do, they discuss, document and write changelogs for easy understanding, it's not fire and forget..
<cosm>
but if it isn't, I'll modify my patch for the older kernel to be compatible with this one
<cm8>
or you fork fbturbo in two and relate each copy to a specific kernel counterpart (that is, if you can't find a changeset that satisfies both base kernels..)
<cosm>
no way
<cm8>
just my 2ct
<cm8>
it'd make the chaos perfect :)
<cosm>
in the worst case I'll make fbturbo detect which kernel it's running on
<cosm>
they've added hardware cursor support
<cm8>
but seems not as complete as with your patch, on ioctl is missing, iirc
<cosm>
but it's broken...
FreezingCold has quit [Ping timeout: 258 seconds]
<cm8>
*one
<cosm>
we could live without the missing ioctl, it's just for setting a 3rd palette color and we're not using it
<cm8>
ok, so it's broken in yet another way you say?
<cosm>
haha, yes
<cosm>
it hardcodes palette colors
<cosm>
it hardcodes the cursor image
<cm8>
last one should be ugly
<cosm>
it hardcodes display size to 720p
<cm8>
:)
<cm8>
yeah, you've written about that a couple of days ago.
<cosm>
and the worst is, the hardcoded cursor is sort of asymmetric
<cosm>
:)
<cm8>
so ultimately a patch would have to throw out their code first and replace it with the implementation you adopted earlier.. oh well..
<cosm>
I think that's what I'll do
<cm8>
quite some effort for something that will be obsolete once mainline is ready, but noone knows yet when this will happen, despite all the progress
<cosm>
the guys working on mainline support were here a few days ago
<cosm>
it sounds like they're making good progress
<cm8>
nice
<cosm>
but lots of things are still not supported
<cm8>
you probably need to decide yourself if it's worth the effort, i'd appreciate it for sure :)
<cosm>
I don't really have any experience with writing good (as in good for mainline) drivers
<cm8>
me neither, but the more code read and written probably won't hurt to getting there :)
<cosm>
but once someone starts working on the graphics subsystem, I hope I'll be able to work with them to have the features needed for XV acceleration
<cosm>
hopefully in a way that's not too different
<cm8>
there is also this dedicated vpu thing - http://linux-rockchip.info/mw/index.php?title=VideoAcceleration - but it means even more work to adopt for linux. I'm sure you've read about it, but it's not of priority. xv support will help a lot for sure.
<cosm>
it would be nice to have it working
<cm8>
ok, gotta leave now. my bicycle needs some love. c u around.
<cosm>
but the ARM cores are powerful enough to decode most types of video
<viric>
I've several: W: Invalid Parameter's tag (0x00000200)!
<viric>
Invalid parameter
<viric>
no wonder it doesn't boot
<viric>
What can it be?
<viric>
ah different bootloaders have different ftl? (1.x, 2.x?)
<viric>
hm I wish I knew the name of the serial port device
<viric>
ah it's ignoring the changes I write in the parameter file. mh
<viric>
definitely my paramters file is broken
cnxsoft has joined #linux-rockchip
<viric>
aaaah rkcrc!!!!!
<viric>
I understood how to write parameters finally
<viric>
cnxsoft: do you know if the picuntu kernel doesn't allow overriding the cmdline in parameters?
<viric>
FlashReadPage error!!,row = 227190
<viric>
FlashReadPage error!!,row = 227190
<viric>
FlashReadPage error!!,row = 227190
<viric>
grmbl may I have bricked it?
<cosm>
regarding the driver linked above - it says 'This software is confidential and proprietary and may be used only as expressly authorized by a licensing agreement from Hantro Products Oy.'
<cosm>
I'm not touching that
<viric>
argh....
<viric>
Kernel boots, but I can't get into recovery mode anymore.
<cosm>
viric: does rkflashtool still connect to the device?
<viric>
no
<viric>
All the mess started when I wrote: rkflashtool w 0 1 < parameters
<viric>
but the file 'parameters' didn't exist....
<cosm>
I'm fairly sure that overwrites the bootloader, not the parameters
<viric>
no, I succesfully wrote the parameters file that way many times
<viric>
start_linux=====132915
<viric>
E:CRC failed!
<viric>
Begin recover...
<viric>
Load failed!
<viric>
GetRemapTbl flag = 1
<viric>
FtlSetSysProtAddr error j= 45
<viric>
that's when it started the 'recover' thing.. maybe it'll take some hours. At every reboot, it seems to restart at the given position.
<viric>
oh! It came back to life!
<viric>
FtlSetSysProtAddr error j= 619
<viric>
powerOn,18253302 18253325 UsbConnected
<viric>
Now I wish I knew how to set the kernel cmdline... these kernels (Linuxium / picuntu) don't seem to accept other cmdlines from the parameters file.
<cosm>
viric: one of the reasons why you're probably better off rolling your own
<cosm>
or rather my fork: https://github.com/lgeek/Linux3188, but I've had 0 reports of someone else trying to use it, so maybe you don't want to start with it
<viric>
let's fetch from the 1st
tonikasch has quit [Quit: Bye!]
<viric>
cosm: is there any defconfig I could rely upon?
<naobsd>
rkcrc is needed if you flash parameter with rkflashtool, but not needed if you flash parameter with Rockchip official tools such as upgrade_tool
<naobsd>
I recommend to use upgrade_tool if you have x86 Linux
<naobsd>
cmdline from parameter can be ignored by kernel (it's very common thing, it's NOT Rockchip or some specific kernel fork special)
naobsd has quit [Quit: Page closed]
ganbold_ has quit [*.net *.split]
mnemoc has quit [*.net *.split]
moofree has quit [*.net *.split]
jcarlos has quit [*.net *.split]
FreezingCold has quit [*.net *.split]
ganbold has quit [*.net *.split]
irsol has quit [*.net *.split]
viric has joined #linux-rockchip
FreezingCold has joined #linux-rockchip
ganbold has joined #linux-rockchip
irsol has joined #linux-rockchip
ganbold_ has joined #linux-rockchip
mnemoc has joined #linux-rockchip
jcarlos has joined #linux-rockchip
moofree has joined #linux-rockchip
irsol_ has joined #linux-rockchip
irsol has quit [Write error: Connection reset by peer]
irsol_ has quit [Changing host]
irsol_ has joined #linux-rockchip
irsol_ is now known as irsol
FreezingCold has quit [Ping timeout: 255 seconds]
FreezingCold has joined #linux-rockchip
ganbold_ has quit [Remote host closed the connection]