_hipboi_ has quit [Read error: Connection timed out]
_hipboi_ has joined #linux-rockchip
cnxsoft has quit [Ping timeout: 246 seconds]
_massi_ has quit [Remote host closed the connection]
_massi_ has joined #linux-rockchip
theskilledworker has joined #linux-rockchip
theskilledworker has quit [Changing host]
theskilledworker has joined #linux-rockchip
_hipboi_ has quit [Read error: Connection timed out]
_hipboi_ has joined #linux-rockchip
<tonikasch>
Hi! Do you know if there is a linux-rockchip (development) mailing list?
<karlp>
most I've seen is the google+ circles, the occasional activity here, and some of the web forums
<tonikasch>
yes... the case is that one non-google user has asked me to join our gtalk conversation and... first it "sucks" to read through this kind of unordered conversations 2) by opening a maling list we could welcome more developers
<tonikasch>
but I don't know who takes care of linux-rockchip.info
<tonikasch>
edito: I don't remember
_hipboi_ has quit [Read error: Connection timed out]
_hipboi_ has joined #linux-rockchip
<tonikasch>
let me issue a whois on the domain xD
<karlp>
yeah, google hangouts are a gross way of having a proper conversation
<tonikasch>
:s
<tonikasch>
well, I've written the tenant of the registry of the domain, let's see what happens
_hipboi_ has quit [Read error: Connection timed out]
_hipboi_ has joined #linux-rockchip
mac-_ is now known as mac-
<tonikasch>
mmm
<tonikasch>
I'll add linux-rockchip mailing list to wiki on linux-rockchip.info (have just found it when trying to create it as the domain owner told me to do so)
cnxsoft has joined #linux-rockchip
_hipboi_ has quit [Read error: Connection timed out]
_hipboi_ has joined #linux-rockchip
cnxsoft has quit [Ping timeout: 246 seconds]
cnxsoft has joined #linux-rockchip
_hipboi_ has quit [Read error: Connection timed out]
_hipboi_ has joined #linux-rockchip
<tonikasch>
ssvb I've managed to get es2gears get a 239.000 fps
<tonikasch>
however, I'm unable to set X to truecolor, so I keep attached to 256 or so colors
<ssvb>
tonikasch: so the OpenGL ES is working now? that's a great news
<ssvb>
about the colors, can you show the /var/log/Xorg.0.log file?
<tonikasch>
yes, one sec
<tonikasch>
mmm, ssvb, do you know if a fbset is needed prior to initialising x?
<ssvb>
not necassarily
<tonikasch>
ok
<tonikasch>
so I comment the fbset thing in /etc/rc.local and reboot, let's see
<tonikasch>
that's without trying to force any depth in xorg.conf
<tonikasch>
if I do the fbset thing and force 24 or 32 in xorg.conf, which as I understand would be truecolor, i get either and error or a window with gradient in oranges and window moved to the right and very strange
<tonikasch>
(i can do a photo and upload it)
<tonikasch>
*take a photo (sorry for my English :)
<ssvb>
right now it's rgb565
<ssvb>
the problems with 32bpp color depth might be in the kernel driver
<tonikasch>
aha... perhaps in rk_fb.c :s
<ssvb>
can you set 32bpp successfully with fbset just for the framebuffer (without doing anything with xorg yet)?
<tonikasch>
mmm, how to do that? I don't understand very well fbset procedures
<ssvb>
btw, are you communicating with the other rockchip / radxa guys?
<tonikasch>
aha, done, let me see dmesg... ok, seems ok
<tonikasch>
I'm communicating with Galland, Omegamoon, linuxium and others through a gtalk conversation
<tonikasch>
but they had given up and now wait for me to publish the procedure
<tonikasch>
I have requested to join googlegroup's linux-rockchip mailing list but even though it was the way, it seems unused as it has only one message dated on 2013
<ssvb>
ok, I just wanted to be sure that the xorg / mali problems get solved for everyone, so that we are done with it :)
<tonikasch>
yes... I will publish everything, now just trying to get things done, later getting original kernel tree, forking, makin commits, documenting, etc
<ssvb>
good
<ssvb>
there is a suspicious line in your log: "[ 23.200] (II) FBTURBO(0): enabled fbdev copyarea acceleration"
<ssvb>
it thinks that the copyarea operation is accelerated, but most likely the ioctl just does not return error
<ssvb>
if you get any problems with moving windows or scrolling, that's likely it
<tonikasch>
let me test that..
<tonikasch>
no, they move well
<tonikasch>
and scrolling...
<ssvb>
ok
<tonikasch>
ok too
<ssvb>
just let me know if you notice any problems
<tonikasch>
ok
<ssvb>
got 32bpp color depth working already?
<tonikasch>
no
<tonikasch>
in fact when I ran those two fbset commands xorg was running and screen gone blank, just sshed and restarted lightdm
_hipboi_ has quit [Read error: Connection timed out]
<tonikasch>
shall i change the xorg.conf to force depth?
_hipboi_ has joined #linux-rockchip
<ssvb>
I can't be totally sure (I don't have a rockship hardware myself), but the symptoms seem to indicate that the kernel framebuffer driver might be behaving a bit funny
nighty^ has joined #linux-rockchip
<ssvb>
for example, if the kernel boots and sets the framebuffer to 32bpp mode right from the start, then xorg is going to to work fine
<tonikasch>
that's the expected result, I guess
<ssvb>
xorg.conf can also specify color depth, but again, xorg is using ioctls for setting the video mode
<tonikasch>
so... should I try setting in CMDLINE fb mode just to test?
<ssvb>
which means that it is asking the kernel framebuffer driver to do this
<tonikasch>
aha
<ssvb>
and if the kernel driver does not behave properly, you may have glitches
<ssvb>
still even the properly working 16bpp mode is a good start
<tonikasch>
:)
<tonikasch>
when saying " if the kernel boots and sets the framebuffer to 32bpp mode right from the start", you mean in CMDLINE or in /etc/rc.local by adding a fbset command?
<ssvb>
in whatever way that works :)
<tonikasch>
aha, ok
<ssvb>
kernel cmdline would be a natural choice
<tonikasch>
I'll test first in /etc/rc.local
<ssvb>
if it is supported by the rk framebuffer driver
<tonikasch>
ah, ok
apxii has joined #linux-rockchip
<apxii>
Hi
<tonikasch>
I'm not sure, that's galland, iam, olegk0 and omegamoon who know on rk framebuffer device
<apxii>
I see a discussion and as i remember, copyarea acceleration isn't working properly.
<apxii>
if you resize a terminal window, it is not works
<apxii>
ssvb, thanks, i have no access to hardware by now, try it later
tonikasch2 has joined #linux-rockchip
<tonikasch2>
well, it works, I dont know if better but it works
<tonikasch2>
(the r3p2 xf86 fbturbo)
<ssvb>
tonikasch: you can perhaps check fps numbers
<tonikasch>
yeah, almost the double: 401.800 fps
<ssvb>
r3p0 and r3p2 behave in a slightly different way and need separate code paths in the xorg driver :(
<tonikasch>
:s
<ssvb>
I was a bit reluctant about supporting both r3p0 and r3p2, because it may be a pain to handle multiple configurations
<tonikasch>
mmmm, I see a mailing list a must now, i'll try contacting the owner of the google group named linux-rockchip...
<tonikasch>
well, whu not supporting only the latter?
FreezingCold has quit [Ping timeout: 252 seconds]
<tonikasch>
s/whu/why/g
<ssvb>
old linux-sunxi kernels have mali r3p0 kernel module
<tonikasch>
:(
<tonikasch>
and there's also that r4p0... :p
<ssvb>
and the users of course expect a painless and smooth upgrade path without any regressions
<tonikasch>
I see
<ssvb>
yeah, I suspect that they very likely have also changed something in r4p0 in an incompatible way
tonikasch2 has quit [Remote host closed the connection]
<tonikasch>
in the beginning I tried placing r4p0 in kernel tree but I wasn't aware of ump ioctls and all that sort of things :p
<tonikasch>
then I copied from a rk3x kernel, and at last I found apxii kernel branch with them included in... r3p2-1_rel1? r3p2-1_rel2? which was a strike of luck
<ssvb>
I think we should just stop at r3p2 and then eventually move to the open source lima drivers
<tonikasch>
i also found handy sunxi-mali doc and that repo containing all userspace libraries and makefiles, and also xf86-video-fbturbo
<tonikasch>
[ 22.880] (==) FBTURBO(0): Default visual is TrueColor
<ssvb>
that's what xorg thinks about the current video mode, if you have problems, then apparently the kernel driver does not agree
<tonikasch>
so it's a kernel driver problem, ok, I'll continue comparing drivers/video/rockchip directories with meld
<ssvb>
you and apxii might want to debug what's happening in the kernel by adding debugging output to the relevant framebuffer ioctls
<tonikasch>
apxii ask me whatever change shall be done
<apxii>
tonikasch, I am not an expert, I just wanted Mali worked on RR
<apxii>
I'll look into rk_fb at afternoon
<tonikasch>
ok
<tonikasch>
I've applied rk_fb.c patched made by Galland and olegk0 to your kernel's rk_fb.c to see if that works out something
<apxii>
they wasn't already there?
<tonikasch>
I guess they weren't on rr-3.0_dev
<tonikasch>
mmm, they won't work for minix neo x7
<tonikasch>
hdmi output is blank from the beginning with patches applied
<tonikasch>
I'll try to apply now only some of them
<apxii>
and what are the patches?
<tonikasch>
well, not .patch files but comparing files with meld and applying differences from the Rockchip-GPU-kernel (omegamoon's) to yours line by line
<tonikasch>
I'm not used to version control systems :(((((
<apxii>
it is not that hard
<tonikasch>
I know, but I tend to leave it for later learning...
<tonikasch>
brb
<theskilledworker>
tonikasch: do you have any kernel I can try on my radxa?